couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: The replicator needs a superuser mode
Date Tue, 16 Aug 2011 18:21:16 GMT
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 <dionne@dionne-associates.com> 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 http://couch/db/_restore.
>>>
>>> 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 <nate-lists@calftrail.com>
wrote:
>>>
>>>> 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 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