Good question! This is something we did consider. After running a few focus groups, we decided it was more useful to guarantee having versions available over a wide range of time.
We didn’t want to force creators to significantly reduce their write frequency in order to not “use up” all available versions in one play session. Even if you only save once when a user leaves your experience, a user could have many play sessions in a single day and effectively erase all of their previous saves from the previous 29 days.
I am honestly a little confused by this post considering I’m not the brightest with datastore coding, what are the ways this might break my datastore script stuff?
Are we eventually going to have a setting to automatically wipe previous versions and keep the most recent one? I personally don’t use previous versions so it might make sense some developers may want an option to only keep a key’s current data.
Thanks for the context. Did the focus group include any creative / building games?
These types of games where an hour of progress from a player building their home/boat/vehicle is a big gap if that player wanted to rewind / restore.
For this use of the versions api where you are trying to provide frequent restore points for the current session the change will force a rewrite to store under seperate keys and cause more and mostly uneeded datastore requests.
It would be good to hear if the dev team is open to feedback on the effect this change has for this use case or would consider a longer grace period?
Unless we missed a prior post about it being changed this is relatively short notice.
These changes will not break existing usage of Data Stores. GetAsync, IncrementAsync, RemoveAsync, SetAsync, UpdateAsync, ListKeysAsync, etc. will continue to work exactly the same way.
The main difference is the number of versions available through ListVersionsAsync, GetVersionAsync, and RemoveVersionAsync. There will now be fewer versions covering a wider timespan.
Please let us know if you still have any questions or concerns.
We don’t have definite plans to do so with these changes, but we’re investigating different ways to bring you all more control over the versioning behavior in each individual experience. If an option to keep only the current version seems useful to you, please open a feature request!
We appreciate your feedback. Yes, we did discuss with creators representing a wide range of experience genres, including building games.
We understand that these changes won’t perfectly meet everyone’s needs, and we do believe this is the best solution with minimal impact to the majority of experiences.
As I mentioned in another reply, we’re looking for ways we can give more, intuitive control over version behavior. If you have suggestions for how we could better meet your use case, please open up a feature request and we can discuss there.
How can I achieve roll-back using data stores versioning? Let’s say I publish an update and it erases people’s data, how do I roll-back to a safe position in time?
Currently (for each key) you need to use ListVersionsAsync to identify the correct version to restore, GetVersionAsync to retrieve that version, and SetAsync to overwrite the current data using the previous version. In the case of accidental deletion, the “current data” would be a special version marked “deleted”. We have a code example in the documentation. GetVersionAtTimeAsync can replace ListVersionsAsync and GetVersionAsync when it’s released later this year.
At this time, there is no automatic process to restore all keys in a Data Store to a particular time.