Hi Patrick, this is true:
if key of the myDoc is lower then the replicator records, then it
means the document hasn't change since last replication.
However, in your example #3 revseqs 5,6, and 7 on Node A happened
after the last replication, so the key for myDoc in the
_all_docs_by_seq view will be greater than the update_seq in the
replication record. Hope that helps,
Adam
On Feb 8, 2009, at 3:11 PM, Patrick Antivackis wrote:
Sorry Paul, but i thought Couch could do miracles.
Adam, back to the _all_docs_by_seq view, if key of the myDoc is
lower then
the replicator records, then it means the document hasn't change
since last
replication. So no conflict or do I still miss something
2009/2/8 Paul Davis <[email protected]>
On Sun, Feb 8, 2009 at 1:48 PM, Adam Kocoloski <[email protected]
>
wrote:
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
As Adam points out, you've got a "Then a miracle happens" step with
checking that rev's 3 and 4 are the same revisions. This means that
the two systems are more or less the same but yours is gonna have
added complexity.
Also remember that _rev lists aren't actually lists, they're trees.
HTH,
Paul Davis
