couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Vander Wilt <>
Subject Re: The replicator needs a superuser mode
Date Tue, 16 Aug 2011 17:13:20 GMT
We've already got replication, _all_docs and some really robust on-disk consistency properties.
For shuttling raw database files between servers, wouldn't rsync be more efficient (and fit
better within existing sysadmin security/deployment structures)?

On Aug 16, 2011, at 9:55 AM, Paul Davis wrote:
> Me and Adam were just mulling over a similar endpoint the other night
> that could be used to generate plain-text backups similar to what
> couchdb-dump and couchdb-load were doing. With the idea that there
> would be some special sauce to pipe from one _dump endpoint directly
> into a different _load handler. Obvious downfall was incremental-ness
> of this. Seems like it'd be doable, but I'm not entirely certain on
> the best method.
> I was also considering this as our full-proof 100% reliable method for
> migrating data between different CouchDB versions which we seem to
> screw up fairly regularly.
> +1 on the idea. Not sure about raw couch files as it limits the wider
> usefulness (and we already have scp).
> On Tue, Aug 16, 2011 at 10:24 AM, Jan Lehnardt <> wrote:
>> This is only slightly related, but I'm dreaming of /db/_dump and /db/_restore endpoints
(the names don't matter, could be one with GET / PUT) that just ships verbatim .couch files
over HTTP. It would be for admins only, it would not be incremental (although we might be
able to add that), and I haven't yet thought through all the concurrency and error case implications,
the above solves more than the proposed problem and in a very different, but I thought I throw
it in the mix.
>> Cheers
>> Jan
>> --
>> On Aug 16, 2011, at 5:08 PM, Robert Newson wrote:
>>> +1 on the intention but we'll need to be careful. The use case is
>>> specifically to allow verbatim migration of databases between servers.
>>> A separate role makes sense as I'm not sure of the consequences of
>>> explicitly granting this ability to the existing _admin role.
>>> B.
>>> On 16 August 2011 15:26, Adam Kocoloski <> wrote:
>>>> One of the principal uses of the replicator is to "make this database look
like that one".  We're unable to do that in the general case today because of the combination
of validation functions and out-of-order document transfers.  It's entirely possible for a
document to be saved in the source DB prior to the installation of a ddoc containing a validation
function that would have rejected the document, for the replicator to install the ddoc in
the target DB before replicating the other document, and for the other document to then be
rejected by the target DB.
>>>> I propose we add a role which allows a user to bypass validation, or else
extend that privilege to the _admin role.  We should still validate updates by default and
add a way (a new qs param, for instance) to indicate that validation should be skipped for
a particular update.  Thoughts?
>>>> Adam

View raw message