On Sun, Feb 8, 2009 at 3:11 PM, Patrick Antivackis <[email protected]> wrote: > Sorry Paul, but i thought Couch could do miracles. >
Heh. Just meant that I think you're assuming that CouchDB is storing data that it isn't. > 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 > The issue is that since you don't have the data to compare against you can't tell if this is a conflict or not. Knowing that the edits came from same original document doesn't help you. And you still have to account for two nodes creating a document with the same id in which case knowing the original _rev doesn't help at all. So in the end it just adds complexity because you now have to store multiple initial _rev's (or deal with them in some other manner). HTH, Paul Davis > 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 >> >
