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.
Data fails to load (either DS error or application error).
Player notices wrong data and rejoins. This can happen a few times depending on the error.
Player reports error to developer
Developer looks through datastore entries and server errors to debug.
If you limit a backup per hour the developer might lose crucial debugging data. Have you considered keeping backups for the first week and then merging the backups to one per day or something similar.
I understand that’s this is a complex issue and there are no solutions to solve everything. But in my experience this is a very common situation.
PS: Are there plans to create DS visualization tools? Also, are there plans to cap DS usage?
Thanks, @Redridge. We appreciate the feedback and understand the scenario. This is something we’ll keep in mind as we think about how to expand customization of this system.
Keep an eye on the Creator Roadmap and here on the DevForum for more info on future Data Stores improvements!
This would be insanely helpful. In a project that I was previously signed onto, we had a tri-attack of issues: exploiting (old codebase with zero safeguards that had to be updated), data corruption (unexpected writes that could not be processed) and versioning (nothing in place to restructure data formats from bad form to a more usable form). All of these issues required considerable effort to do global rollbacks for and supporting old systems for a period of time before removing them and simply consigning the data of all players who didn’t log in during the grace period to oblivion.
Fetching the nearest version to a timestamp and doing global rollbacks is a considerable chore right now. GetVersionAtTimeAsync would be a massive boon to this effort alone by simplifying the process to retreive the best available backup but still requires some manual maintenance and preservation of rollback systems in the game code. I would love to be able to mark an entire store as “needs rollback” and then the next get/update for any key on that marked store would get a previous version rather than the current. Would totally cut out all the intricacies of rolling back.