I feel like there is a really vital point being missed in this thread. If you use UpdateAsync the same way you would use SetAsync, meaning you only set data, almost all the value in using UpdateAsync is lost. UpdateAsync can be super useful, but to maximize its usefulness, your data structures need to revolve around changes and transitions in data. Consider the following cases:
-
You are using SetAsync twice at the same time, for incrementing how many “points” a player has. Data has now been lost because it was overwritten. Ouch!
-
You use UpdateAsync twice at the same time for the same reason, but you use something akin to a “data id” as mentioned in this thread. Data has now been lost because an entire set of data was rejected, because it had the wrong id. Ouch!
How do we solve this? By locally storing what has changed, and then using UpdateAsync to commit those changes. When a player gains points, use UpdateAsync, and increment the old value, retrieved from the UpdateAsync callback, by the amount changed. This is what the entire purpose of UpdateAsync is, because it gives you the most recent data in the callback. You can use this on complex tables, all you need is the correct implementation. And if you want optimal data safety, you should.
slight edits for wording