couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Antivackis <patrick.antivac...@gmail.com>
Subject Re: proposed replication rev history changes
Date Sun, 08 Feb 2009 21:01:53 GMT
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
>>>
>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message