couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <adam.kocolo...@gmail.com>
Subject Re: proposed replication rev history changes
Date Sun, 08 Feb 2009 20:17:29 GMT
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
View raw message