Should I be using a combined datastore rather than just saving this userData table all with one key?
Yes, it’s easier to work with and has the same end effect while being more easily understood as individual units.
1 Like
Is it really necessary for my situation though? Like would It be the difference to my game’s datastore breaking or not?
No, but it’s something you should be using anyway and is eventually going to be the default and further prioritized and optimized for.
Alright, I’ll give it a shot, appreciate the help!
1 Like
If you need a somewhat good idea on how to use Combined datastores, you can refer to this:
3 Likes
Hello, I’m planning on using your datastore2 Module, but one thing that is not clear to me is about data store names and keys.
In normal datastore we do
local Data = DataStore:GetAsync("User-" ..player.UserId)
and that creates new masterKey in datastore, which then we can use to insert other elements of data in, like money etc
InDataStore2 we just do
local Data = DataStore2("key", player)
I suppose player in DataStore2 is, what would GetAsync(“User-” …player.UserId) be in a normal datastore and “key” is what then would be inserted inside that datastore key named after player, is that right?
I also want to know what datastore name is. Is every single data saved with this module saved in same datastore with different keys and scopes, or does it create datastore per Game or per place?
Just “key”. Don’t worry about any player.UserId stuff.
No I’m not worrying about anything. I just don’t want to use this module with ambiguity. What do you mean by Just “Key”?
When I use DataStore2(“Key”, Player) I save “Key” in player(Actual key for DataStore). So if told otherwise, Table is named after Player and “Key” is key in that table.
Am I right?
Yes, it handles anything to make the data store specific to the user for you.
So This
local TableOfData = DataStore2("Key", Player)
Loks like this
TableOfData = {["Player"] = {["Key"] = {} } }
No, don’t worry about implementation details. Just know that it separates the player.
What do you mean by “Separates the Player”?
local dataStore = DataStore2("key", player)
…will always get the data for that player. You don’t have to worry about it getting some other player’s data or anything, which is the reason you’d do .. player.UserId in normal data stores.
1 Like
Yeah I understand that, of course, but my concern was about understanding the way it looks like. Key is child of-whatever ways module implements creating DataStore for my player- that table and I can create as many keys as I want and all of them will be within players boundaries AKA same table.
If you specify the player, it’ll be “within players boundaries”. If you use combined data stores, it’ll be the same table. If you don’t, it won’t but it’ll still be exclusive to that player.
Okay now I understand everything. So when saving dictionaries I should use combined data stores and not this?
Having an all encompassing user data store like what seems to be in that post is worse and less ergonomic than combined data stores, yes.
1 Like
Thank you for clarifying that to me.
1 Like
If I use combined data stores, I will still have to get all values i want to store separately and then Combine them, but if I do that in playerAdded then I will have to do it every time player joins, is that correct way of doing it? I will be able to get this combined data after that and read it for other purposes as ONE won’t I? What’s difference between combined data Stores and GetTable? Can I use GetTable to save Dictionaries instead of CombinedDataStores?
1 Like