couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: The replicator needs a superuser mode
Date Tue, 16 Aug 2011 16:55:48 GMT
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 <jan@apache.org> 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 <kocolosk@apache.org> 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
>
>

Mime
View raw message