Batch Get-, Update-, SetAsync

[Corecii]

Batch Get-, Update-, and SetAsync would allow for more complex systems using ROBLOX’s datastores. A batch Get-, Set-, or UpdateAsync request would execute multiple requests at once.

One thing I definitely hope to see with this is the ability for multiple actions in a batch succeed only if all of the actions in the batch succeed. This will help with datastore systems that require multiple keys.
Currently, if one has a system with multiple keys that rely on each other, it can require a ton of UpdateAsync calls to make sure that if anything fails half-way through it can be corrected later. (Execute & mark pending on key 1, execute & mark pending on key 2, remove pending on key 1, remove pending on key 2)

Another advantage I hope to see is lowering the amount of requests that it takes to set multiple keys. This would be a great advantage if the system that datastores use allows for it.

[buildthomas]

A better term would be “transactions” instead of batches. It’s exactly what you describe in the second paragraph.

Also mentioned here a while back:

Atomic transactions for multiple DataStore Updates

Sometimes multiple DataStore keys depend on eachother directly or indirectly (e.g. my game, where multiple keys form a single save slot since the 65k characters limit isn’t always enough – and having a central key storing information referring to these keys, which ones exist etc.). Updating multiple keys at once is sometimes just unavoidable, but ensuring they all happen atomically is pretty important. Sometimes DataStore just dies out in the middle of writing to multiple keys for a short while…

[woot3 (Woot)]

You could definitely improve your current method by using a system more like this. You would write your save to a new set of keys entirely, and when the save is complete you would update the users current save version to point to the new save. This means there is no need to set certain parts as pending.

This all said, I would find this useful in general for other things so I can definitely see how this could be beneficial.

[Corecii]

That is a neat way to do things. I do something similar for saving versions of data so that a bug or update won’t cause data loss.

In the specific case I was thinking of, I don’t think this system will work. The two keys are for different things: one is for part of the world, one is for the player. Many players will interact with the world key/data so it cannot be saved in the same place as possibly thousands of player data versions.

I could hold separate versions for each key, and only update both when I’ve finished working with and saving the data of each, but that still takes 4 requests but allows changes to be made to the data while I’m doing work on them, which would lead to differences between player data and and world data.