Why does the DataStore2 still save the value even tho it is the same as when the player joined?
It shouldn’t be if you don’t call :Set. It prints a log, but says that it doesn’t save the data as it hasn’t changed.
If you call :Set, the data is marked as dirty, even if the value is the same (if I remember right).
1 Like
Can I use different MasterKey for different places?
For example: Place A uses DataA as a MasterKey, place B uses DataB as a MasterKey
As long as it’s not the same GAME, yes. If it is the same game, sorry, the data will collide.
1 Like
Why is the Roblox Model different from the Github version even tho the Roblox Model is newer? I also experience shutdown saving issues with the one from Roblox. ( The Github version has almost 2x the amount of lines of code )
https://www.roblox.com/library/1936396537/DataStore2-Data-Loss-Prevention-and-Caching
1 Like
The Roblox model is not newer, I don’t know what you’re talking about. It hasn’t been updated in a year or so for a few reasons.
- I literally can’t update it. When I made DataStore2 a package, it completely broke publishing of it for some reason, and if I remember right it doesn’t show up in the toolbox.
- It encourages people to require by ID, which they should not be doing.
- It’s not worth my time when just using GitHub is more ergonomic for me.
That’s because it’s broken, and you should not use it. Use the one from GitHub like the documentation says.
2 Likes
Why does it say :
“Use require(1936396537) to have an updated version of DataStore2.”
in the Script?
Did you forget to change it.
Btw. I love your work
You said this:
That the backups page is revelant if you’re using Standard or OrderedBackups.
Why…?
Standard does not keep any backups.
I prove this when using a DataStore debugger (kind of a proxy/bridge), and noticed that there’s no calls for any backups.
onPlayerAdded:
Server closed:
Is there a reason why you say it’s relevant?
I mean, for compatibility later on, sure, maybe, but Standard DOES NOT keep backups.
My guess is that a retry on :GetAsync() counts as a backup. (It’s good, just not as good as backups lol)
Because he/she/they literally can’t update the module to say it other-wise.
Where does it say that? I will remove it.
1 Like
Read the rest of the page. The “backups” page is for when data stores error, and it gives default data instead without saving. The saving method does not matter.
1 Like
Does this mean you never found data that maybe had collided? Like for example, datastores are currently a bit weird, and maybe it returned nil every time; and you marked the “new” data as current data. Did that NEVER happen? I mean, there’s no way of losing data with DS2, IT KEEPS EVERY, EVERY. SINGLE. VERSION as a backup.
We’ve been using Datastore2 on our game(Warrior Cats: Ultimate Edition - Roblox) for over a year now and it has never happened for us.
This is because if populated datastores started returning nil, this would be an error on roblox’s side. Not to mention if something went wrong like this the getasync call would likely just throw an error.
When an error is thrown Datastore2 just loads a backup that doesn’t overwrite the true data, so this has never been a problem for us.
1 Like
Actually no, a lot of times :GetAsync() calls when DataStores are unstable, they might just return nil and not error. It’s the biggest reason for data loss.
Datastores returning nil is expected behavior when the datastore has never been accessed. Additionally, there is no way to sanity check this since you can’t view any datastores if they are all returning nil. An error like this would be unavoidable and is incredibly unlikely since most times we have experienced a roblox-side datastore issue it has just errored.
No, I mean returning nil even though there’s data.
One solution to this, because :GetAsync() caches data, is to use UpdateAsync, and get the value it returns. That value is not cached. And then try until there’s data, or if you tried too much.
The backups page on the documentation talks about this.
And it does not error. It just pretends there’s no data, this is pretty common, I believe berezaa talked about this on some official posts.
Feel free to file a PR to remove that line, should be an easy web edit.
“A lot of times” is an overstatement. When this happens, it’s a big deal that Roblox engineers work quickly to resolve. This has not happened to me in any noticable amount in practice.
1 Like
True, I think “alot” is a bit much, but when it does happen you don’t get much of a heads up. So it’s always good to retry (:SetBackup(n) on DS2)