You should also read the post. It’s not necessarily about preventing data loss because there’s no surefire way to do so when we have zero control over the servers that the data is uploaded to. Even then, data loss is not something that can be permanently prevented but it can be heavily mitigated to give that comforting feel that your servers are fail proof.
UpdateAsync has more usefulness than often thought. No one’s going to hound you for not using it but people are going to pitch that recommendation out for you. In some cases, if you’re working on a project, this may prompt a rewrite depending on the decision of a project head.
Not necessarily. Both methods are equally at risk for data loss or incorrect updates if you have “bad coding structure”. The difference is that SetAsync forces data. It doesn’t respect conflicting calls, it doesn’t transform data, it doesn’t validate data and you can’t cancel it once you initiate it. Obviously you can set up your own code but you can’t get all the behaviours from UpdateAsync in an API incorporating SetAsync (such as overriding calls).
There isn’t much to see in the first place. I could use general examples, avoiding any custom developed APIs.
SetAsync:
local Data = {} -- Data
DataStore:SetAsync("Key", Data) -- Save
UpdateAsync:
local Data = {}
local NO_SAVE = false
DataStore:UpdateAsync("Key", function(oldData)
if NO_SAVE then
return nil -- Cancel the save
end
if oldData then -- Something exists
-- Merge contents and return table
else
return Data -- If there's no old data, use current set
end
return nil -- If no code above this returns anything, cancel save
end)
This point ignores a lot of the merit to UpdateAsync raised in this thread. Reasons have been provided as to why UpdateAsync is powerful and useful. I don’t feel like parroting those points, but this is not the only benefit.
This whole thread and the discussions in the responses should be reason enough? No method is better than another, though one method is more appropriate than another depending on the presented scenario. I’m not sure what point you’re trying to make here.
That depends on what kind of difficulty you’re referencing. It can be difficult to work with DataStore failures in mind. Difficulty using the actual API is a different story of understanding how to apply the service and use it’s methods to achieve your goal.
You do, if you wrap it in a pcall. The only time you don’t is if the call is successful and doesn’t return an intended value (e.g. the incident report wherein DataStores were caching and returning nil instead of actual data).
You know this as well. UpdateAsync is a callback, it returns the data that is entered to the key in the DataStore after the call is completed (whether it saves that data or not). This is their actual data. You can also confirm, with this return, whether it saved or not.