Alright so, to start this off, I am using Datastores for a game I’m working on. I am also way too familiar with having experience in the industry where certain things are possible there but, aren’t here.
For instance as this thread suggests, there’s no viable way to reset a datastore. I have to fallback to changing a key to anything other than itself and while this does work to an extent, it also causes issues in a test setting. I do not think that changing a datastore or the key works or should even be encouraged because of how poor practice that is.
If I was doing a database test in the real world, I would not… under any circumstance allow the key and the value attached to remain persistent in database even after I don’t need it. Why? Because, it’s a complete and total waste of space and can overwrite data you actually need. In addition, if you were to look at it visually, the entire table would be cluttered with entries which makes it harder for me to actually get whatever it is I need, done.
This brings me to studio. Even after I press stop, it still retains the same data. This poses an annoyance since as a developer, I am much more likely to make a mistake, ruin the entry and then, have to start all over again with another datastore name simply because, it doesn’t reset.
I’d appreciate if there was an option to treat datastores in studio as a temporary store so this way, it can reset (given that the developer wants to) and I wouldn’t have to stack up a bunch of datastores simply because of something dumb. Testing in studio should allow for dumb mistakes whereas production really shouldn’t.
If I am missing something, please let me know. So far, after a bunch of searching, I came up empty with anything that is remotely viable and wouldn’t increase the amount of entries for no good reason.
Just checking: ephemeral DataStores are on the roadmap, which allows temporary data storage. No details have been provided on the feature thus far but would this hypothetically resolve or help your use case? I can imagine what it might entail when it goes live.
I’m wagering guesses here since there’s no information on the feature so far, but it does sound self explanatory. I doubt that it’d reset on its own so it’s not exactly temporary in the sense of “until the session ends” but temporary in the sense of “expires after X amount of time”. It depends on how fast you enter and exit Studio test sessions though, TTL might not be an appropriate alternative to session-only data (or just entirely a non-solution).
If that’s not helpful, then I know buildthomas created a module that can emulate DataStores in Studio but use DataStoreService for live games, so essentially there’s little to no work needed on your behalf for switching between testing DataStores in Studio and performing actual data reading/writing in live games. That’s available at MockDataStoreService.
I’d have to see what this actually entails but, from the name, probably.
This seems pretty cool but, stuff like this where datastores are already painful, I really don’t want to rely on a library that could break at any moment due to a random change. It would give a false sense of “oh hey this works” then, be utterly disappointed when Roblox decides to ruin that sense of false hope. This seems like a useful thing for CI but, as a temporary solution this might work. I still wish that Roblox had a more official solution provided.
The nice thing here is that if such breakage occurs, it would also break real games that rely on that datastore behavior, and the change would likely be reverted.
If your datastore interactions aren’t very arcane I think that module is safe to use as a test environment. If you do find issues just file them on the Github page.
Definitely agree. Using it right now and it works fine. Thanks for creating this. Saved me a lot of pain. Highly recommend for others facing a similar issue.