couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: proposed replication rev history changes
Date Sun, 08 Feb 2009 20:17:20 GMT
On Sun, Feb 8, 2009 at 3:11 PM, Patrick Antivackis
<patrick.antivackis@gmail.com> 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 <paul.joseph.davis@gmail.com>
>
>> On Sun, Feb 8, 2009 at 1:48 PM, Adam Kocoloski <adam.kocoloski@gmail.com>
>> 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
>>
>

Mime
View raw message