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 20:11:32 GMT
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