Hi Adam, Ok thanks, after logging couch_rep, i catch it. As the Node just store the replicator record of the source and not both the record of the source and the record of the target.
2009/2/8 Adam Kocoloski <[email protected]> > 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 >>> >>> >
