1

In the code below, an item is added to a collaborative list within a compound operation. In a VALUES_ADDED event handler on the list, another compound operation is started. When I run the code, I get the following error message: Exception: Uncaught Error: gapi.drive.realtime.Error: {type: invalid_compound_operation, message: "Already committed this local change.", isFatal: true}

It seems like this would not be an uncommon occurrence and arose naturally in my application, although in a more complicated way, so I can't just move the map assignment into the original compound operation. I also couldn't find any reference to such a restriction in the realtime api guide or reference documentation. Is there any way to begin a new compound operation in a call stack above a compound operation ending?

var va = function(event) {
  doc.getModel().beginCompoundOperation('b');
  doc.getModel().getRoot().get('map').set('key', 'value');
  doc.getModel().endCompoundOperation();
};
doc.getModel().getRoot().get('list').addEventListener(gapi.drive.realtime.EventType.VALUES_ADDED, va);
doc.getModel().beginCompoundOperation('a');
doc.getModel().getRoot().get('list').push(100);
doc.getModel().endCompoundOperation();
Christopher Best
  • 466
  • 4
  • 14

1 Answers1

3

In general you should never write to the Realtime model in an event listener. Doing so can result in unnecessary writes. For example, in your code, every single collaborator on the document will write whenever the list is modified, which is probably not what you wanted. It's also easy to inadvertently create write cycles among multiple clients.

We don't have any plans to remove this restriction, although I will ask our documentation team to see if they can add a better explanation.

Generally our customers have not had issues with moving the writes into the original compound op - could you provide me with more detail on why this is impractical for your application?

Thanks, Brian

Brian Cairns
  • 411
  • 2
  • 4
  • Context: what I'm actually doing in the event handler is setting cursor information. A "cursor" is a pointer to an item in a a collab list. Issue 1: all collaborators may write their cursor info on delete, because if the item their cursor was on gets deleted, the cursor has to be reassigned. Issue 2: the cursor moves to a newly added item in a list, so I could put it in the original CO, but I also want the cursor to move there when the item is added on a redo, when I don't have access to the CO, so I'm doing it in the event handler – Christopher Best Sep 25 '15 at 14:11
  • 1
    Are you using IndexReferences to track the cursor? That should handle a lot of what you are trying to do.. – Cheryl Simon Sep 27 '15 at 16:53
  • Yes I switched to using an IndexReference and it resolves both of the issues I described – Christopher Best Sep 30 '15 at 20:56