couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: The replicator needs a superuser mode
Date Tue, 16 Aug 2011 18:29:17 GMT
Hmm, if we used a separate role we'd need a multi-step process to trigger the replication

1) create the database
2) have an admin grant the _skip_validation role on that DB to the replicator's user_ctx
3) trigger the replication

Kind of annoying.  Certainly would be simpler to allow _admins to do this if just by adding
a skip_validation=true parameter to write requests.


On Aug 16, 2011, at 2:21 PM, Robert Newson wrote:

> no objection to special role. As in my opening statement, would be
> concerned about adding it to _admin without devoting more thought to
> possible unintended consequences.
> b.
> On 16 August 2011 19:13, Robert Dionne <> wrote:
>> No objection, just the question of why the need for a new role, why not use admin?
>> On Aug 16, 2011, at 2:10 PM, Adam Kocoloski wrote:
>>> Wow, this thread got hijacked a bit :)  Anyone object to the special role that
has the "skip validation" superpower?
>>> Adam
>>> On Aug 16, 2011, at 1:51 PM, Jan Lehnardt wrote:
>>>> Both rsync an scp won't allow me to do curl http://couch/db/_dump | curl
>>>> I acknowledge that similar solutions exist, but using the http transport
allows for more fun things down the road.
>>>> See what we are doing with _changes today where DbUpdateNotifications nearly
do the same thing.
>>>> Cheers
>>>> Jan
>>>> --
>>>> On 16.08.2011, at 19:13, Nathan Vander Wilt <>
>>>>> 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)?
>>>>> -nvw
>>>>> 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
>>>>>> the best method.
>>>>>> I was also considering this as our full-proof 100% reliable method
>>>>>> 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 <>
>>>>>>> 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
>>>>>>>> A separate role makes sense as I'm not sure of the consequences
>>>>>>>> explicitly granting this ability to the existing _admin role.
>>>>>>>> B.
>>>>>>>> On 16 August 2011 15:26, Adam Kocoloski <>
>>>>>>>>> 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