Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.212.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <E60FA7AA-6435-4126-89D3-DBA853E33A40@apache.org>
References: <EBDEACDE-17FD-4DD5-8E67-D5A13D69F88E@apache.org>
 <CABvT1DE=GhUmQ4ge8Q1OhDxDofPvZ2ok_kQSin2a1Yca3pegjg@mail.gmail.com>
 <E60FA7AA-6435-4126-89D3-DBA853E33A40@apache.org>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Tue, 16 Aug 2011 11:55:48 -0500
Message-ID: 
 <CAJ_m3YD_jjUnBrLf7x8MRv5PWS0nzmGA1GdL5BWjRgShWCKatg@mail.gmail.com>
Subject: Re: The replicator needs a superuser mode
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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/_res=
tore endpoints (the names don't matter, could be one with GET / PUT) that j=
ust 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 hav=
en't yet thought through all the concurrency and error case implications, t=
he 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 l=
ook like that one". =A0We're unable to do that in the general case today be=
cause of the combination of validation functions and out-of-order document =
transfers. =A0It's entirely possible for a document to be saved in the sour=
ce DB prior to the installation of a ddoc containing a validation function =
that would have rejected the document, for the replicator to install the dd=
oc in the target DB before replicating the other document, and for the othe=
r document to then be rejected by the target DB.
>>>
>>> I propose we add a role which allows a user to bypass validation, or el=
se extend that privilege to the _admin role. =A0We should still validate up=
dates by default and add a way (a new qs param, for instance) to indicate t=
hat validation should be skipped for a particular update. =A0Thoughts?
>>>
>>> Adam
>
>