Add capability for commit batches on documents

[sensslen]

Whenever we want loro to store changes, we need to call commit() on the loro document a map is associated with. We can get this document from the map.

In our application we need a way to batch changes. Before we started loro we used to have commit batches which would take all changes and only once we finished that batch the commit() would be called. We used to allow for nested commit batches and thus only the last batch would actually commit the changes. With loro we would like to do something very similar. To do this we currently have to keep a shadow object hierarchy in our application code which allows us to wrap the document to provide this functionality.

Ideally we would like to be able to delegate these operations to loro, as loro already needs to maintain an object tree with the document as root. If the document supported commit batches we could simply start a batch on the document an entity is associated with and not worry about any shadow object hierarchy.

It would be very nice if we could add this functionality for loro.

[zxch3n]

Hi @sensslen, I don't quite understand your requirements. Could you elaborate on the API and code example you need?

[zxch3n]

What happens if the outer commit session finishes before the inner one? It will always wait for the last one to finish before actually committing, right?

Can you share why this is useful in a more general sense? I'm not quite sure whether it should be handled inside Loro directly, as it adds complexity and its behavior is undefined if the users call doc.commit directly before a session finished

[sensslen]

I wold assume that the last commit batch that closes actually performs the commit.I would assume that calling commit would still be a normal commit. I would consider this a usage error, so it could also be undefined behavior....

[sensslen]

The reason this is useful is that we want to very closely control which actions are batched together. Sometimes this involves edits to nested maps. Without this feature we may end up with inconsistent state on some commits. To avoid this we use the described feature. Currently we keep the state only in memory and thus maintain the model structure ourselves. When switching to crdt as our storage model, we have two options. Either our crdt library supports commit batching (which it does not) or we wrap and implement these fields described feature ourselves. However this requires that our application maintains a shadow object hierarchy, so that we can get a reference to the wrapped document so that we can implement these fields described batching.

[zxch3n]

Why would it make the app enter an inconsistent state?

[sensslen]

Because some inner properties only make sense if an outer state has a specific value. If designed carefully, this could be avoided - I agree. However we're dealing with quite some legacy here...