Requirement OP9 specifies what to do on a node when a document is found to contain a DELETE operation. This is what it says.
Nodes MUST delete all operations of a document once it has been deleted.
The obvious reason this doesn't make sense is that we need to keep the delete operation itself in order to replicate the deletion to other nodes. So this would be nice to at least correct. However there are some edge case issues which need addressing even after making that fix.
If after receiving a DELETE operation then a node will immediately remove all other operations from the related document. This becomes a problem in the following (similar but subtly different) cases:
A node receives a DELETE operation as part of a contributing authors' log which it has not seen before. If the log doesn't contain the CREATE operation, and all other operations had already been purged, there would be no way to connect the log to any document,
Any number of UPDATE operations were published before the DELETE by the same author (meaning they themselves connect the DELETE operation to the document) but not yet replicated out to any other node (in the case of offline usage). These "connecting" operations would then be deleted, and once replication occurs, other nodes would receive a DELETE operation which they can no longer connect to the graph. If they're lucky, they have seen contributions by this author before, and so could infer which document it is a part of, but this is not guaranteed, and also does not protect against dishonest nodes (although let's not go there as it gets hairy once anything is deleted).
We don't need to come up with the solution for these problems right now, but in fixing the current specification we could maybe account for them.
Requirement
OP9specifies what to do on a node when a document is found to contain aDELETEoperation. This is what it says.Nodes MUST delete all operations of a document once it has been deleted.The obvious reason this doesn't make sense is that we need to keep the delete operation itself in order to replicate the deletion to other nodes. So this would be nice to at least correct. However there are some edge case issues which need addressing even after making that fix.
If after receiving a
DELETEoperation then a node will immediately remove all other operations from the related document. This becomes a problem in the following (similar but subtly different) cases:DELETEoperation as part of a contributing authors' log which it has not seen before. If the log doesn't contain theCREATEoperation, and all other operations had already been purged, there would be no way to connect the log to any document,UPDATEoperations were published before theDELETEby the same author (meaning they themselves connect theDELETEoperation to the document) but not yet replicated out to any other node (in the case of offline usage). These "connecting" operations would then be deleted, and once replication occurs, other nodes would receive aDELETEoperation which they can no longer connect to the graph. If they're lucky, they have seen contributions by this author before, and so could infer which document it is a part of, but this is not guaranteed, and also does not protect against dishonest nodes (although let's not go there as it gets hairy once anything is deleted).We don't need to come up with the solution for these problems right now, but in fixing the current specification we could maybe account for them.