Regardless the underlying mechanisms, there's still a logical distinction between updates and inserts, and here the proposed algorithms seem relevant, if I understand, only for inserted rows: step 4 of reading says "
The client code culls rows where the transactionUUID existed in the IncompleteTransactions table." which means, applied to the Inventory case, that it will not return any Entity that is currently modified in an ongoing transaction. Which would not be the desired behaviour for us, we'd like to have the pre-transaction state.
It's explicitly written in the post, quoting:
"This is just an example, one that is reasonably performant for ledger-style non-updated inserts. For transactions involving updates to possibly existing data, more effort is required, generally the client needs to be smart enough to merge updates based on a timestamp, with a periodic batch job that cleans out obsolete inserts."
Or is there something I haven't understood here?