I think changing the requests to per experience is much better for cross server interactions, such as messaging service, memorystore or match making, where some datastore requests may be “off loaded” to one server on behalf of the cross server interaction, without intervening with the limits of the server itself and potentially impacting players in one server. This will literally eliminate any type of such worry or consideration of looking into custom implementations of when and where to off load requests. Awesome change.
I really love this! I love that this allows creators to see the datastores, the keys in each one, and even the versions of each key. It really helps if a player experiences data loss.
However, I noticed that I have a lot of “trash” data stores from old scripts/modules I haven’t used in years. Will there ever be a way to delete entire DataStores in the future?
1 Like
I used to pray for times like this
I think I completely missed what makes this so awesome the first time I read it - so any key in the datastore can now be Get/Set the maximum times the universe allows? No more per-key rate limits?
Thank god, I hate rate limits.
I don’t know why it took me so long to question this, but will Enum.DataStoreRequestType be adjusted to suit the new approach? As in the layout itself, since SetAsync and RemoveAsync are grouped in Enum.DataStoreRequestType.SetIncrementAsync, but they will have different request limits.
I can make assumptions, such as Enum.DataStoreRequestType.SetIncrementAsync and Enum.DataStoreRequestType.SetIncrementSortedAsync being combined, Enum.DataStoreRequestType.RemoveAsync being added. Enum.DataStoreRequestType.ListAsync documentation being adjusted to include ListDataStoresAsync. But I cannot act on assumptions, as my approach using datastores relies heavily on these requestTypes to ensure I have enough budget to splurge when a server goes down, or enough to continue looking through keys/versions (mainly for this**).
2 Likes
i mean, they host everything for you, they have to make money somehow… it doesn’t just grow on trees man, i get 73% is a pretty unfair amount but they gotta do what they gotta do to in order to even pay you in the first place
Now that I have finally had the visual bug of 100MB resolved; my “Total Size” remains above what I’ve been granted for the game.
My main problem is caused by the old data format my game used to use based on “Datastore2” which would create a new key within a scope for each “version” thus inflating my datastore significantly.
Could we please see introduction for devs to have the capability to select individual “datastores” entirely and select for entire “scopes” within the selected “datastore” to wipe all keys excluding the latest one added to that “scope” for those selected datastores to prevent complete dataloss of players who remain to have all their data saved via. that old system?
If we can’t get that; could we get the ability to run a script and run through all created datastores in that respective game along with being unrestricted to fetch all the latest keys saved of each and every scope within that datastore without restriction and be capable we can do a one-time solution to run our data conversion systems without the need of these older players that haven’t played in a while (or was just one-time players) to join the game?
With this as the converter implemented for my game it deletes datastores left over from systems such as my case used to use Datastore2 providing minimal issues and ultimately freeup the entire space and will absolutely benefit the total size to be far far lower and likely be no more than 400MB at an extreme over-estimation.
I personally believe these kinds of features would be critical for any games that have been essentially blocked from benefiting from these changes by a open source module used years before.
And no; I’ve not been able to find any DMs about what my options to resolve this are as has been mentioned multiple times by members from the Roblox team here.
I hope this can be answered by someone at Roblox to provide some transparency at what cases like these will be able to resolve issues caused by such flawed systems as used as an example Datastore2 within this reply.
Edit: Could we also get the ability to view how much “Size” each datastore key uses individually?
2 Likes
Thanks for the report, I will DM you about your case
1 Like
Okay. I’ve been mulling this over, looking at numbers, and making careful considerations. I’ve come to a verdict.
I wouldn’t be entirely upset with this update, if and only if there were a way to effectively delete and remove datastores from our games. I mean completely remove entire datastores, not just deleting all the keys or whatever. I say this because old, unused datastores presently will take up space regardless of if we even need them anymore. This is completely unacceptable.
If you guys add methods to effectively clean up datastores (or better yet: just add an option to clear & remove datastores from the new datastore manager!), then I wouldn’t be too upset with this update. But since there is presently no way to do that, I only see this being an enormous headache. Especially for my game, which has to store data for potentially THOUSANDS of procedurally-generated, persistent star systems.
Until you do that, this update remains one that I will staunchly oppose.
p.s. if security/accidental deletions is a concern with deleting datastores, you can mitigate that.
- Require a verified phone, authenticator app code, and/or security key to remove a datastore.
- Require completing a captcha to remove a datastore.
- Have a warning pop-up show up that does not let you close it for 5 or so seconds. This would force people to slow down and think about what they’re doing, and I wouldn’t mind it for such a dangerous feature.
- Have a countdown timer that allows a dev to cancel a datastore removal.
1 Like