Compatibility for eventually-consistent systems
This is a complex issue with a potentially extreme amount of background information, justifying a fairly simple set of changes:
All record types which have an
idshould also include a
All update and delete methods should accept the
revisionIdof a record, instead of its
- Clients should reference revisions, rather than RESTful identities, when making alterations to existing data.
- For UI code to be correct, it must ensure it passes the correct parameter.
- For backend systems which represent a single source of truth and do not support versioning,
revisionIdcan simply be provided with the same value as
idto no ill effects.
I think this is the simplest API change that can accommodate the diverse spectrum of potential technologies to implement against— from the high-trust end of centralised, immediately consistent systems all the way through to low-trust, fully distributed and eventually-consistent networks in which forks are unavoidable.
- InfoCentral's technical properties of distributed information (no mutable references)
- Holochain 'RSM' migration guide (low-level CRUD)
- Release announcement about the upgraded HDK (high-level description of changes)
- Example code showing one mechanism for dealing with this, which just picks the latest item but unfortunately in doing so also makes it possible to attack a network by writing data with a newer timestamp than some record you want to replace and then reconnecting and allowing it to sync.