I think you’re undermining UpdateAsync a little too much, as I’ve noticed over time through your posts.
UpdateAsync isn’t solely used to check old values - in fact, that’s hardly the purpose of the function at all. In terms of the old value being passed, there’s many circumstances in which you could use the old value for, but that all depends on how you go about your system. You shouldn’t really throw that value away though, so as far as misusage of UpdateAsync goes, I’ll bite.
There are a plethora of benefits for using UpdateAsync over SetAsync. Remember that SetAsync is a setter, so it has no regard for anything else other than forcing down a value. UpdateAsync takes a more respectful approach towards data.
| Item | SetAsync | UpdateAsync | Notes |
|---|---|---|---|
| Callback | False | True | UpdateAsync returns the new data that was updated into a DataStore, so if you fancy using that return value for something, you can. SetAsync is one and done; you either get an error value or you don’t. |
| Respect calls | False | True | If you have multiple servers potentially editing data (includes servers that write to data in less than 6 seconds apart), SetAsync calls will overstep each other and effectively brute force a value into a DataStore. |
| Overwrite data | True | False | UpdateAsync takes up one request from the budget, but the function is called as many times as needed until the data is marked as saved. If respecting other calls isn’t necessary, SetAsync is good. |
| Data validation | False | True | SetAsync essentially takes a value and smacks it onto a key. UpdateAsync has two forms of data validation; one done internally (as implied, I don’t quite know how it works though) as well as a developer-implemented data validation. Yes, you could accomplish it by writing a wrapper function with SetAsync, but that’s reinventing the wheel. |
| Reject save attempts | False | True | Returning nil to UpdateAsync cancels a data write call. SetAsync cannot be cancelled. I’ve yet to test whether cancelling an UpdateAsync call still uses part of the budget - if it does, I’ll be pretty heartbroken. |
Using UpdateAsync like SetAsync and disregarding the benefits or application of either is where the danger comes from, among other practices. Sometimes, bad habits may develop depending on the kinds of messages that circulate around (I can’t imagine someone using GetAsync pointlessly right after using SetAsync, but you never know).
Otherwise, I can’t, in good faith, agree that SetAsync is better than UpdateAsync, because that’s untrue. The benefits of either are dependent on the context of your code and the scenario you have to work with. UpdateAsync has its uses over SetAsync, as does SetAsync over UpdateAsync.
I made a lot of posts discussing UpdateAsync in a certain thread, since you aren’t alone in thinking that UpdateAsync has little merit over SetAsync. The thread itself is an isolated example that relates to player data saving, however the points I brought up mostly talk about the functions themselves rather than the presented scenario. There was also a good point brought up by another poster on that thread in regards to the usage of both.