Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of patrick.antivackis@gmail.com
 designates 209.85.218.163 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;
        b=pqZbdkmabIpPgENTo96wdEnXW2u7PXZmMEjjE6FeDP4hWZjh10gLR5ZJgXtgauCX4T
         0S20OUPVLG53H6OFHeerLVzeMzDKthtFpT+rcfksGwgRLw4d3DB+yYK38cqYoIM065i0
         VYpjr8fCKrqtrrUUnsIIQ0ktR4poRX9LDAyqI=
MIME-Version: 1.0
In-Reply-To: <2A30A4F1-C443-465D-A025-36704A628883@gmail.com>
References: <5B2D5ED2-6B85-41D7-BA78-3DD4BE7AFE13@apache.org>
	 <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>
	 <2A30A4F1-C443-465D-A025-36704A628883@gmail.com>
Date: Sun, 8 Feb 2009 22:01:53 +0100
Message-ID: <7060483c0902081301u268c4cc2qe237bf5c7d42ff7f@mail.gmail.com>
Subject: Re: proposed replication rev history changes
From: Patrick Antivackis <patrick.antivackis@gmail.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=001636c5b1f447dd7b04626e90a5

--001636c5b1f447dd7b04626e90a5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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 <adam.kocoloski@gmail.com>

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

--001636c5b1f447dd7b04626e90a5--