couchbase-lite-core icon indicating copy to clipboard operation
couchbase-lite-core copied to clipboard

Make sync work across VV upgrades

Open snej opened this issue 7 months ago • 7 comments

The transition from tree-based revids to version vectors is tricky for replication, and the prior approach (adding a fake 'legacy' version when creating the vector) didn't turn out to work.

Instead, now:

  1. when a doc is upgraded in memory to a VectorRecord it keeps its tree-based/legacy revids.
  2. When the doc is saved, it creates a version vector for the local Revision but also remembers the prior legacy revid.
  3. Remote Revisions keep their tree-based IDs until they're replaced by newer VV revisions (pulled or pushed).

As a result, revision histories now consist of a VV and/or legacy revids. The version vector, if present, always comes first. The legacy IDs at the end are what allow the recipient of a revision (an active or passive puller) to match up an incoming version vector with a local legacy revid.

(It's also possible for a rev history sent by the replicator to consist only of legacy IDs, even after the upgrade. This happens if a doc was updated locally before the app upgrade but not pushed until after. It can also happen on a pull for the same reason.)

There's an open question of how long we need to keep the legacy revid of the document. It only needs to be used once per remote, but in a P2P scenario you never know if you might have to sync with some new peer that hasn't upgraded that doc yet. In any case the revid isn't very big (~24 bytes) and it only occurs in pre-existing docs, so it may not be worth removing.

snej avatar Nov 17 '23 18:11 snej