couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: Unique instance IDs?
Date Thu, 15 Dec 2011 00:19:33 GMT
On Wed, Dec 14, 2011 at 10:52, Alex Besogonov <alex.besogonov@gmail.com> wrote:
> On Wed, Dec 14, 2011 at 3:55 AM, Randall Leeds <randall.leeds@gmail.com> wrote:
>> I think you miss the point that was made above about mirrors, still,
>> unless I misunderstand. B may have other changes interleaves with
>> those received from A, whether from interactive updates or other
>> replications, making its hashes different.
> Of course. But that's not a problem, because we save all the A's
> changeset hashes
> that we've seen during the replication. B's resulting hash would be
> different, but we don't
> care about it.
>
> Also, since merging is commutative and associative we can reorder changesets
> in any way, so interleaving changes in itself should be OK.

I might need you to restart your solution for me to understand. If the
hash tree isn't of the sequence or id index, then I'm not seeing what
this applies to except the rev tree of a single document. Documents do
already have a sort of hash, as you identified, in their revision id.
Comparing the presence of these on the client and server is already
part of the replication protocol. However, since CouchDB is _not_ a
versioned document store ("_rev is only for MVCC"), there's no need to
optimize the problem of diffing the revs present. Only the newest revs
need ever be replicated.

The sequence number checkpointing is an optimization to avoid
comparing the revs for all documents. I think progress looks like
finding a way to skip large chunks of the seq index because they
contain changes already received, possibly from elsewhere.

So I'm not sure what your solution proposes. Can you go further?

-Randall

Mime
View raw message