Closed mattmccutchen closed 7 years ago
Let me think about the transaction_id
field of the saved document. It might be used in later undo or redo calls. I'll have to take a careful look at the code.
Let's leave it there for the moment. There was some reason the transaction_id
needed to be recorded on documents. It might have just been so that documents with subsequent updates can't have inserts undone. The set of tests is too limited at the moment to ensure that any cases relating to not setting a transaction_id
are caught.
This field caused the document to be restored as soft-deleted, which is bogus even if the only concrete consequence for an app that doesn't look at the "deleted" field is that a subsequent remove of the document will fail with "Document not found for removal". It's unclear to me what purpose setting the field ever served.
Here's a test case to demonstrate the problem. I wrote it using the test app since this was the easiest way, but I don't know if it's worth adding to our test suite.
Also, is there a purpose for setting the
transaction_id
of the saved document, or shall I remove that too while I'm here? AFAICT, non-instant hard delete don't set it.