I’ve made datastore modules in the past, but whenever I show them to other scripters they say it’s not as efficient as it could be, and some say it’s a weird way to script it. Idk if weird is a good thing or bad thing, but I want to know if I can improve this script so it is efficient and is guaranteed to work. I also would like to know what I’m doing wrong, and what I should be doing instead. Here is the module that I scripted:
GetAsync and SetAsync can error due to datastore outage or reaching limits. You could pcall to prevent it from stopping the whole routine and build in some sort of queue to try failed requests again every X seconds until they succeed.
There’s also a lot of code that does literally nothing. Like if statements with nothing in the code block. From an efficiency point of view they don’t really do much, but from a human readability point of view they are confusing and unnecessary.
Which if statements would those unnecessary ones be?
Lines 34, 35 and 67 can be completely removed:
Lines 114-116 could be replaced with:
if savedWhichTool[name] ~= true then
Instead of having an empty block just to get the else block:
Making the blocks’ intentions clearer can help someone reading the code to understand it more easily.
List of most common problems in Data Store modules developers deal with off the top of my head:
- Upon failure to load a player profile, module silently starts a fresh empty player save
- Player quickly joins another server and finds out that his data rolled back to a 10 minutes older version (Last session didn’t save in time for the next session to receive it)
- Exceeding DataStore call budget
If a truly perfect DataStore module is what you’re after, you might want to look into using UpdateAsync, possibly even to a point where you replace GetAsync and SetAsync with UpdateAsync (It can be used both for updating and retrieving data!) as it will never cache your data and will wait out any pending changes made to a value.
Since players can hop through game servers of the same game, the DataStore module made for handling player profiles falls under this criteria in official documentation for UpdateAsync:
Then again this theory of using UpdateAsync was kind of partially denied by engineers at RDC 2019… You will only know the truth as you scan through more forum posts about DataStore and making a few tests yourself.
Whenever you’re planning to improve an already made thing, always try to search for each minor detail or bug that could be fixed. As @BanTech suggested, you can search for common problems people meet and find a way to prevent them for happening, or you can make the datastore more efficient buy slowly improving a little bit from there and here, replacing 1 if statment with something more efficient is already good enough.
The reason DataStore2 one of the most known datastore module is better than the DataStore service, is because bareeza, its creator, made a system where each second or so a timestamp is taken and data is saved at each timestamp, which was littearly just using the DataStore service itself, but in an abusive way. Perhaps you can figure out a way that’s more efficient to save data.