DataStoreKey, DataStoreKeyInfo, DataStoreInfo, DataStoreOptions, DataStoreSetOptions, DataStoreObjectVersionInfo, and DataStoreKeyVersionInfo could all either be dictionaries or have their own data types, like the *Params types.
Using instances for these makes code very verbose, to enable these new settings you have to create a DataStoreOptions instance, call a method on that instance with a dictionary, and then use that as a parameter to GetDataStore.
All of the Instance properties seem to be unused on these instances, which is very confusing.
I would prefer dictionaries or new data types be used instead of these instance, to make code less verbose and to make them less confusing (do these Instances really need to store all of the information associated with an instance? Name, Parent, Children, etc.).
This is a very awesome and helpful update. I thank everyone who contributed to this update. The roblox team is very hard working and are great at what they do. Again, I can’t thank you enough roblox, always making your platform better and better.
-Cats767_99
I feel this would fit better as a separate reply. I’ve been using the post I’m replying to as a way of tracking the way I’m tinkering with the new API.
tl;dr of what I want to say is: if you want to use (or test) ListDataStoresAsync, do not use the iterPageItems code sample on the Developer Hub (found in Pages instance documentation). If you’re like me and plucked that function off to use by virtue of listing APIs returning Pages objects, you will encounter this same issue where not all your DataStores will get listed.
I got some follow up communication on all of my testing and ListDataStoresAsync does not work with the coroutine that iterPageItems creates (as of right now, not sure if there’ll be any addressing of this down the line). Write your own iterator or for loop generator. I was given a code sample and then later wrote my own which successfully iterated all my experience’s DataStores.
In contrast with the test code I ran in the post I’m replying to, my new code only needs to use a single ListDataStoresAsync call instead of 60 which didn’t even catch my full list of DataStores. That code caught only 135 DataStores while my new code catches all ~320 DataStores that have ever been in use across the 4+ years this experience has been developed for.
Below I’ve provided a better code sample which will allow you to see every single DataStore your experience has ever used.
--- ListDataStoresAsync test
-- @author colbert2677
local DataStoreService = game:GetService("DataStoreService")
local startClock = os.clock()
local pages = DataStoreService:ListDataStoresAsync()
local dataStoreNames = {}
while not pages.IsFinished do
local page = pages:GetCurrentPage()
for _, value in ipairs(page) do
table.insert(dataStoreNames, value.DataStoreName)
end
if not pages.IsFinished then
pages:AdvanceToNextPageAsync()
end
end
print(#dataStoreNames, dataStoreNames)
print(string.format("Took %f to iterate DataStores", os.clock() - startClock))
(~4.316013 seconds to catalogue ~320 DataStores)
Check your console for a dropdown beside a number and open it out. You’ll get a list of strings of the names of DataStores. You can also iterate through the table if you’d like.
Does this have automatic transactions? It was really annoying to constantly have old data replaced as no transactions were in place, so I had to create my own system for that. Are they built in now?
I think these new DataStore features are great, however for GDPR requests, it would be nice if there was some kind of automated system that could remove all data with a specific tag if a user issues a GDPR request- having developers manually erase data can be a bit messy.
Thats an excellent idea! But for this to work it would need to be a must for all games. Takes a bit of a learning curve, but its totally doable and adjustable just like FE.
Also I`m hyped for ProfileService update, thanks loleris!
It looks like you can associate a UserId with a key when using SetAsync now in this version of DataStores for this exact reason. It even says so and recommends doing so on the devhub article for DataStore v2.
Edit: There’s also similar support for this in UpdateAsync as well.
Yesyesyesyesyesyesyesyes! I have been waiting for this update for months. I need to know when this update will come out. The feature I want the most, though, is saving instances. That was a feature of the legacy Data Persistence, so I really want that to be added.
This is nice and all, but it seems super wasteful for things like session locking, where only one value in a big table is being changed, which would create thousands of useless versions for active players. Is there anything I can do to avoid straining the systems?
Versioning isn’t useless with session-locking
ProfileService added features to check older versions of data, and also overwrite the newest version with them, if there’s any little accident on your part, it’s super helpful.
This isn’t a problem, in fact I was able to get a single key to have 7k+ versions while cleaning older versions was disabled, and that didn’t make datastore requests any slower. My :UpdateAsync calls still took around 0.25-0.75~ seconds.
No, older versions already get cleaned up after 30 days, Roblox expects a bunch of versions to be created at all times, and that’s fine, they knew what they were getting themselves into, and they commited to it.
+ This doesn’t affect speed, efficiency, or anything else for you.
It may not do so yet, but at least the feature is there with the intention of automatically handling them in the future (at least, I’d imagine that’s the whole point of it existing in the first place).
Are there any plans to increase datastore limits, mainly for get requests? In my game players can build “machines”, each machine has a GUID key used to save it to datastores, then I have an array of metadata for each machine inside the player’s data
The list below is populated with the metadata from the player’s data file. The metadata only has the name and creator ID of the machine. When a player clicks on one of the buttons, the game makes a get request to download the machine’s content. Current datastore limitations means players can only safely click on 10 buttons per minute at most, and when browsing the library looking for new machines that limit gets hit very fast
Depending on your game, I would say that 6 seconds is a reasonable wait time between different machines. I don’t think someone would just move on to another machine that quickly to require more than 10 requests a minute. But then again, I have no idea how these machines properly work and if it would be better for someone to move on after 1-5 seconds.
Edit: I forgot about there being other players, so my idea probably doesn’t work.
:
Absolutely pumped to get this in my games
