Some gimmicks with these upcoming DataStore APIs that should be fixed

Hio. I noticed the following API changes appeared in Roblox’s CI branch recently:

Added Class DataStoreInfo : Instance [NotCreatable]
	Added Property string DataStoreInfo.Name [ReadOnly]
	Added Property int64 DataStoreInfo.UpdatedTime [ReadOnly]
	Added Property int64 DataStoreInfo.createdTime [ReadOnly]

Added Class GetDataStoreOptions : Instance [NotReplicated]
	Added Function void GetDataStoreOptions:setExperimentalFeatures(Dictionary experimentalFeatures)

Added Class DataStoreEnumerationPages : Pages [NotCreatable] [NotReplicated]

Added Function Instance DataStoreService:ListDataStoresAsync(string prefix = "", int pageSize = 0) [Yields]

Added Enum ScopeOptions
	Added EnumItem ScopeOptions.AllKeys : 0

Added Tag [Yields] to Function DataStoreService:GetDataStore

Changed the parameters of Function DataStoreService:GetDataStore 
	from: (string name, string scope = "global")
	  to: (string name, Variant scope, Instance options = nil)

There are a few problems that I think should be addressed before this goes out to production:

Members should use PascalCase rather than camelCase.

All of Roblox’s non-deprecated and non-internal Lua APIs should use PascalCase for the sake of consistency with all other existing APIs.

This issue is present with DataStoreInfo.createdTime and GetDataStoreOptions:setExperimentalFeatures.

GetDataStoreOptions really should not be an Instance.

For something that ultimately just wraps a dictionary, I feel like these options should just be passed in as an optional dictionary, with documentation provided on the DevHub. Maybe there are bigger plans for this which facilitate the need for this to be an Instance, but as of right now it just seems very weird.

The declaration of DataStoreInfo.Name overloads Instance.Name?

This is an interesting case which might hold despite my scrutiny, but I still think its an unusual roundabout way to make the name of a DataStoreInfo immutable. It feels like this should be something handled internally rather than explicitly redefining the Name property to make it read-only.

If someone were to get a DataStoreInfo visible in the DataModel to be selected in Roblox Studio’s explorer window, attempting to rename it might cause some interesting problems.


Let me know if you have any comments or feedback on my points here.
Thank you!

20 Likes

Is there a reason why scope would become Variant?
And since it’s no longer marked as optional, it should break any code which doesn’t pass scope?

Due to it being a Variant type, nil would be accepted as a valid input, so, this would not break functionality unless there is no longer code in the function to turn nil values into “global”. I do think its rather strange that the API changed in this way but its likely some code structure for the function changed slightly if I had to guess.

@Maximum_ADHD
I agree that its strange for the Name property to be overwritten here, this has the potential to create some very weird behaviours. The (still mostly undocumented) File instance originally had a (now deprecated) FileName property which was readonly. Now it uses the Name of the instance itself (not an overload), which is, obviously not read only, but, even if no extra behavior exists on top of the property, I would expect no behavior change to take place if you change the name of the instance.

ScopeOptions should be renamed to something like DataStoreScopeOptions in my opinion, it seems a little confusing how its currently named.

I’m not talking about passing nil for scope, I’m talking about passing nothing for scope
DataStoreService:GetDataStore("abc",nil) is different from DataStoreService:GetDataStore"abc"
Variant doesn’t imply that none is accepted, it only implies any value.

For instance the function setmetatable(table,Variant)

setmetatable({},nil) -- ok
setmetatable{} --> missing argument #2 to 'setmetatable' (nil or table expected)

Ah, this makes sense! (Gosh, none vs nil gets confusing)
Yeah, I think that would cause breakage in this case, uh oh.

That’s a yikes, I had no idea Roblox did that.

I have gripes with other API Roblox provides that also returns an unneeded Instance, when a tuple or dictionary would suffice greatly.

Kinda wish they didn’t do this :confused:

Thanks for the report! We’ve filed a ticket to our internal database.

1 Like