I have unfortunately went through 3 different data structures in my game’s lifetime, so there is quite a few:
Structure 1
Used 3 different datastores (for whatever reason?) with 1 key per player each
Structure 2
Used DataStore2, which means there is a whole datastore and ordered datastore per player
Both have an x number of keys, depending on how many times the data was loaded/saved
Structure 3
Uses ProfileService, so it’s simply 1 key per player in a single datastore
This got really annoying to clear manually, so I just made a local plugin to do it. It works, but doing it on the web without having to fire up studio would save some time too. With this amount of complication, I really don’t think it would be worth the trouble on Roblox’s end though.
I guess it depends on read performance and limits, if I could read millions of keys within milliseconds, then I suppose a query API (e.g., MongoDB) wouldn’t be necessary?
I suppose, yeah, though I am not sure how efficient that would be for millions of entries, and how it would work in the future if buffers were to ever be stored natively in binary rather than string representation (e.g., base64).
Mostly for migrating to a different database solution, but it could be useful for in-depth data analysis without running into rate limits.
Also, are there any plans to introduce API for proper ACID compliant transactions that can work with multiple entries and data stores which would be particularly useful for trading between many players, and cross-server trading without worrying about all sorts of issues (e.g., duplication)?
For example, let’s say you have a sphere that can be filled with player’s coins, each player can insert their coins, and once the sphere is filled, everyone receives a reward. This system would require at least 2 data stores, one for the sphere, and other for player data. When rewarding every contributor, you would reward everyone and reset the sphere, and in case failure, nothing should update.
EDIT: I will probably file a feature request and link it here.
First of all, I absolutely love this update. Great work!
One thing I’d really like is an easier way to delete, edit, or replace data stores. Right now, if you want to switch to a new data store without losing player data, it’s possible, but it’s hard and takes a lot of time, especially for new developers. I think it would be awesome if we could manage all of this directly from the Creator Hub. Also, almost every Roblox game uses data stores, so making them easier to manage should be a priority to help all Roblox developers.
I think it would make sense when most keys are stored by userID for there to be a toggle that can automatically fetch the user’s username as well. (by like picking out the longest string of numbers in the key or something). It wouldn’t work properly for all keys but most. It would be a cool feature when searching through the data. It might not be worth the expenses of retrieving that info though.
Yes this was pretty much what I meant.
This could help save maybe some time when searching through smaller datastores, but also to give the developer some more clarification on who they’re looking at.
I’m going to be completely honest here, I was just looking through my datastores when it first came out, and since my game has a relatively small userbase, I could just easily look at what people had. Now that I think about it, I could just save the player’s username if I wanted to see it while in the data. There’s probably better ways to spend the time (and resources) it would take to make this.
The only true benefit would be like to be able to search by username to see a #1 leaderboard person’s data or something to make sure it’s accurate or something like that. So yeah, only very niche use cases.
Thank you for diligently seeking feedback on every reply though! The community is really appreciating it!
Diffing took almost 30 seconds on the first attempt
PlayerData/global/465545098 is almost 9,000 lines (currently 8,767), as my game supports multiple player save slots – mainly consisting of inventory items and quests data.
Should mention that my average players save file is not nearly as this large.
Experience Id: 6555402658
Start Place Id: 117117535314266
About time! This should be baked in from the start. We shouldn’t have to rely on 3rd party tools and plugins to do this. Great win though, it’s a yes from me!
I switched to testing with random data but I encountered another issue… Roblox seems to be inflating my buffer’s values by a significant amount during serialization.
I lowered the buffer’s byte length 3949995 and when saving with the module I use, it tells me the serialized data is 5266695 bytes (module adds less than a thousand bytes). I then tried saving the buffer directly to a datastore to rule out the module being the cause and it still fails for being over 4000000 bytes despite the headroom of 50k bytes. Meaning it’s safe to assume the 5266695 byte value given by the module I use is accurate. That’s a 33% increase!
Is there anything I can do about this, other than lowering my buffer’s byte length significantly to compensate for the inflated size?
Buffer → DataStore has about 25% overhead (IIRC, I don’t work on that code) because for historical reasons the data has to go through json parts of the stack rather than staying in a pure binary data form.
Not sure if I should make a bug report or what, but when I open up the Data Stores Manager on one of my older projects it’s filled with tons of data stores that don’t belong to that experience
You’re right, that is much cleaner. Not much thought went into us saving the tycoon data. We just save every button purchase as a sepperate value. Only benefit of our current method is that it makes it easier to query. Appreciate your feedback, will definitly be keeping that in mind.
I’ve seen several reports of people confused by the permissions- people with the legacy “Create and edit community experiences.” in group configuration. It appears this new page does not take into account legacy permissions
With the launch of the Data Stores Managers, some users reported seeing unfamiliar data in their DataStores, which may have been written due to a bug briefly exposed and patched in 2019. While the patch resolved the bug, this unfamiliar data might now be visible in the Data Stores Manager, and you may proceed with deleting its contents.
Thank you for your patience and for working with us through this situation.
DataStores Team
