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


Reply via email to