Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.132.246 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=R5cPuySNVAMWaJcg7nQnZO4m3htRnV7Ilj+X1lAZn3IicdPjymk47wjjiup8+65jxE
         3pALiMCOeqxJmo6pen7JKAcL8S1snMEGcLzMmMnsLZ2PmEXGdBz3y8gXNNLmw3aGiK+A
         znOEKkX2fBB1f2bvc3xE/6gDSIQ/XeTiE826c=
MIME-Version: 1.0
In-Reply-To: <7060483c0902081211s2462eed3gae6c458317ee5a94@mail.gmail.com>
References: <5B2D5ED2-6B85-41D7-BA78-3DD4BE7AFE13@apache.org>
	 <e2111bbb0902080810g472103e8ube9f53966299af89@mail.gmail.com>
	 <7060483c0902080850w126d4208yd50bb65921c9137d@mail.gmail.com>
	 <e2111bbb0902080910k4fb05f0bq33ed8bbeb461873e@mail.gmail.com>
	 <7060483c0902080914w1eadaf12h8525e4af53c5aee9@mail.gmail.com>
	 <e2111bbb0902080918v46afe68ata62fd00dba15c4d0@mail.gmail.com>
	 <7060483c0902081038l30df1bd7h1219a7a079a7b00a@mail.gmail.com>
	 <2C826622-ECCD-46A8-9BF1-A3B4A140CE02@gmail.com>
	 <e2111bbb0902081056n6cbf1527se0141f345b98e27f@mail.gmail.com>
	 <7060483c0902081211s2462eed3gae6c458317ee5a94@mail.gmail.com>
Date: Sun, 8 Feb 2009 15:17:20 -0500
Message-ID: <e2111bbb0902081217i3d673164u9dc1a389385778bb@mail.gmail.com>
Subject: Re: proposed replication rev history changes
From: Paul Davis <paul.joseph.davis@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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
>>
>