couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: The replicator needs a superuser mode
Date Tue, 16 Aug 2011 15:24:40 GMT
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.


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