dagdb
dagdb copied to clipboard
feat: rev-tree per key
In a recent discussion, the idea of including a CID-based rev-chain at the key-level was dicussed. This is particularly useful for conflict resolution, but comes with some other benefits, such as the ability to "roll-back" specific keys or combinations of keys, etc. There are drawbacks of course, for instance, without some slightly more complicated sync strategies, any two peers syncing a given key will end up pulling the whole history for a key, whether they want it or not. Additionally, tombstones make this sync process slightly more nuanced. In any case, an initial pass with some tests here would be fantastic.
The proposal, as I understand it, would be to:
- Modify the
Operation
schema type to take a (nullable)prev
key which would be of typeLink
. - Modify the set and delete methods on kv to include the
prev
cid reference- This would require an additional
get
that rides on the current transaction
- This would require an additional
- Modify some of the tests that are expecting a specific number of blocks based on not including the extra links on a type
- Leave everything else "as is" for now, with the new information available as we think through edge cases
I'm certainly missing things here, but at a high level, this seems to cover most of the initial conceptualization