couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan <>
Subject Re: Saving changes
Date Wed, 27 Mar 2013 03:23:03 GMT
On Tue, Mar 26, 2013 at 10:27 PM, Jens Alfke <> wrote:

> The replication protocol is interactive, so you can’t do things the same
> way. For instance, a push replication first sends a _revs_diff request to
> tell the remote server which new revisions it has that the remote _might_
> be interested in; then the remote responds by listing the subset of those
> revisions that it doesn’t have yet, and what prior revisions of those
> documents it does have. Then the source PUTs the revisions one by one.

This is really, really helpful. Thanks!

You could write something that would do this in a less-optimal
> non-interactive way. It would remember the last time it synced to the
> target, gather up all the revisions that have happened since that sequence,
> and bundle them up into a file. It would work fairly well if the target
> server only replicates with the source server, i.e. it has no way to get
> these replications from somewhere else. If you have a more complex set of
> replications, then the source can end up sending way too much stuff because
> the target may already have gotten those same revisions from somewhere else.

I think that's just a fact of life for my application. In a worst case, two
different sources could want to replicate to a target at the same time,
before the target checks for new messages. In this case, there's no way to
avoid both sources uploading messages.

> I'm looking for
> > more information on how to build something that does that. So far all
> I've
> > found is
> I’ve documented the replication protocol here:
> The APIs that the replicator calls are all documented in the CouchDB wiki
> (partly because I made sure to add documentation for the ones that weren’t
> documented as I ran into them):

Thank you so much for your work documenting this.


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