You can use the scope variable for this when retrieving the datastore. If you don’t know what that is, it’s basically the “Folder” the datastore saves the data too. All you’d have to do for this is replace an example like this:
local DataStore = DataStoreService:GetDataStore("Example") -- the in-game production data used
with this:
local DataStore = DataStoreService:GetDataStore("Example", "development") -- a different scope that the data is saved too.
It’s still the same datastore but just saving the data in a different area or scope.
I don’t think you have to convert them. The functionality should just work for any existing datastores: “You can now directly use the new functionality for both your existing data and new data!”
Does this mean we’ll be able to query data? For example, if I had a load of shop items being stored in a DataStore, could players then enter keywords into a shop UI search bar and have the shop respond with any items that have either a matching product id, #tags, name or description?
I have a question, if a player joins after not playing for 1.5 months, notices that something is wrong, leaves and asks for a rollback - that would not be possible right? Since the now latest version is the one with a problem, and any older version is older than 30 days.
Can you please give us examples of how metadata should be tagged in the “right” way so that when you implement the ability to query in the future we can be sure we have stored our data in preparation for this feature?
Currently GetGlobalDataStore returns GlobalDataStore i.e. no v2 features. We are currently working on changes to return DataStore object for DataStoreService:GetGlobalDataStore as well.
This should happen in the next few weeks. After this we will have 2 kinds of datastores.
The querying feature will be added in the future.
For now you can use the ListKeysAsync api to provide simple search experiences.
For example the in game shop contains various item categories such as tools, weapons, consumables etc. and different items in each category. Then in datastore you can store the item information with a key format like “{category}/{itemName}”.
This way you can do a prefix search for the item category to list all items in the category. And ListKeysAsync without any prefix to get all items in the shop from all categories.
No. V2 is backwards compatible your existing code should work as it is and the data has been migrated behind the scenes. The data is already versioned you should be able to list keys and list versions for your existing data using new APIs.
ListKeysAsync currently feels to limiting due to the fact that there is no way to get the value of the key without a datastore request. This makes it impossible to use for listing purposes (if the value is required).
This is such a nice feature to finally dish out, first the memory expansion and now this! It’s great how we can finally use built-in DataStores rather than being encouraged to use external DataStores due to the previous size limit, call limit, and it’s not-so vast functionality. I wonder what user-created modules will be made including this change!
I understand that it’s currently limited, but I should’ve stated in future.
What I should’ve asked is will it eventually be possible to query similarly to how you might an SQL database; using a shop as an example:
SELECT * FROM shopDataStore WHERE key = "sword" OR metadata.description CONTAINS "sparkles" LIMIT 25
I have use cases beyond this example; however, I’d rather not state publicly on how I intend to use new DataStore features rather than outsourcing data to a third party service.
Thank you for the quick reply. I really like the ability to search keys by prefix, great addition. In my case I’m letting a player name an asset they create. Later I will add the ability for that player, or other players, to search for assets by name. So in this scenario, based on the new features, I will tack on metadata that stores the name of the asset in hopes that later I can use the query feature to find assets using partial name matches, etc. Is this an example of what you envision the query feature being used for? I wouldn’t use the key prefix feature for this since the name of the asset can change, as one example of why I want to use metadata instead.