On Feb 8, 2009, at 1:38 PM, Patrick Antivackis wrote:
3)
NodeA :
_id : myDoc _rev : 7-moe actual-rev-history [1-bart, 2-lisa, 3-homer,
4-marge, 5-patty, 6-selma, 7-moe] damien-rev-history [5-patty, 6-
selma,
7-moe] patrick-damien-rev-history [1-bart, 6-selma, 7-moe]
NodeB :
_id : myDoc _rev : 4-marge actual-rev-history [1-bart, 2-lisa, 3-
homer,
4-marge] damien-rev-history [ 2-lisa, 3-homer, 4-marge]
patrick-damien-rev-history [1-bart, 3-homer, 4-marge]
Actual revision system : OK can find there is no conflict, NodeA is
just up
to date compare to nodeB
Damien's proposal : KO comparing [5-patty, 6-selma, 7-moe] with [ 2-
lisa,
3-homer, 4-marge]
Keeping first revision combined with Damien's proposal :we compare
[1-bart,
6-selma, 7-moe] with [1-bart, 3-homer, 4-marge], sure it's the same
document, but with have rev 6 and 7 on NodeA and rev 3 and 4 on
NodeB. Using
the replication record on both source and target, we can find than
revision
3 and 4 were already replicated, so for sure rev 6 and 7 coming from
NodeA
are updates of the document. So OK we can find there is no conflict,
NodeA
is just up to date compare to nodeB
So compared to Damien's proposal, keeping first revision seems a
good idea
to me.
Do I miss something or am I wrong ?
The replication records don't include the fact that 3 and 4 made it to
Node B. The replicator consumes the _all_docs_by_seq view, which only
stores the latest revision for each document. The replication history
only tracks the index in that view at the end of each replication, so
it knows which documents have not changed in the interim. Best,
Adam