Great update, especially since using OrderedDatastores as a backup is no longer required.*
*As long as 30 days is enough. Would be nice to see a feature to modify this.
Really exited for this API to become to default, hope that it can be done seamlessly unlike Pivot, Content, and other APIs that seemed less thought-out. Thanks for the great update!
Will this allow datastore entries to be automatically deleted upon GPDR requests? Does it need to be exactly UserID? Would be nice to have a bit more explanation on this point, as manually auditing GPDR requests is not fun & takes valuable time. Thanks!
Good point, you probably should be able to do that. Normal GetDataStore calls that don’t specify a scope pass nil as the second argument and internally it just changes that argument to the string “global” (as per the default value listing). I’m just not sure about the live behaviour right now since it just released and wrote it in on a whim. Ideally should return the same DataStores as now.
This is AMAZING and long overdue! Nothing else to say about these changes.
The only other reasonable thing that the DataStoreService is missing is batch/transactional queries. Trading systems aren’t able to be created with 100% certainty that players will end up with the correct items. Networks can fail, DataStore limits can be reached, etc. Having a way to do 2 (or more) Set/UpdateAsync calls at the same time + auto rollback if one fails would completely fix the headaches that developers have implementing trading systems.
I could be wrong, but I thought I saw this feature on the 2020/2021 roadmap. It doesn’t seem to be there now.
Ah okay, makes sense. I think DataStore options refers to the instance though I could be wrong? DataStoreOptions seems to be nil by default, and it isn’t documented on the devhub datatype index. Though, under DataStoreOptions it doesn’t have a v2 property, weird.
Yeah, SetExperimentalFeatures takes a dictionary. Not that helpful that it wasn’t listed off the bat in the original thread on how to do that, or maybe they were in the process of updating the Developer Hub and the page was cached when I went to check. API’s relatively straightforward though.
Around a year and a half ago I worked on a simulator, and waited something like 7 seconds after the player joined before calling GetAsync just to make sure previous session probably saved. Now if old data for some reason took longer than that to save (and yes it attempted to save repeatedly on fail), they’d lose a session’s worth of progress, which isn’t the end of the world (I wasn’t smart enough to use session locking at the time). But I received reports on a daily basis of data being completely wiped, and estimated it was happening on average once in every 10,000 sessions or so. However it appeared to happen more or less often depending on the weather.
After switching to Bereza’s method of saving every session in a list and fetching the most recent one, the reports of complete data wipes essentially stopped.
It has a version history now. That is cool, but is there a point of using this over Datastore2? Datastore2 has version history, except there is no 30 day deletion. I’m confused as to if this should replace Datastore2. What specifically about the data versioning is superior? Is it faster or more efficient?
I believe it’s an expression, or at least that’s what I intended it to be. What I meant was it seems like it was dependent on what kind of day Roblox was having. Some days there’s a lot of outages and such.
You can typically call both immediately. UpdateAsync will internally retry itself until the transform function returns either with data to be written to the key or nil to cancel the write. Get and Set operations normally shouldn’t take too long unless other logic is processing data and it yields; and any time spent actually writing to the data service would be on Roblox’s side.
Can follow up in PMs if you’d like. Just had a brief scare reading that post and thinking that GetAsync might’ve been returning the wrong things again, lol. The most likely cause for a GetAsync returning nil is either running into the cache, improper processing or something on Roblox’s side. If you’ve been good for now then you shouldn’t have anything to worry about; and if not, worth a bug report writeup.
DataStore V2 is new and they’ve apparently done some migrations and versioning on our behalf but I wouldn’t put it pass a migration to potentially miss on data, not sure what their process there was. Always worth a post if you encounter any new issues with this new API.
I haven’t gotten around to playing with it yet, but I will! Soon:tm:.
I know @dragonknightflies has responded to a bunch of my feature requests regarding datastores and to finally see this out is amazing. I actually have no real words. Automatic Versioning and Datastore and Key Listing are incredibly powerful and help to make datastores feasible while maintaining a level of safety than before. Data Tagging is one of the most useful things I can possibly think of and I am incredibly surprised that Roblox decided to add it in. Not many people know about it but, it helps a lot when indexing large sets of data and being able to break that initial set into tags is incredible.
The only gripe that I can think of is that datastores prove to not be well-suited during the developmental phase. I think that temporary datastores that can be instanced within studio for developmental testing would prove to be equally as powerful to Developers and lessen the amount of data-prone errors that Developers face since it provides a testing layer per-se that does not affect all users or rather, on production.
As a developer, we do have alternative libraries that offer something similar by emulating the functionality that datastores have but, so far it has not been added as native which is a bit restricting when you don’t want to push database changes to production w/o it possibly going wrong.
