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 23:23:32 GMT
On Tue, Aug 16, 2011 at 4:46 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
> -1 on _skip_validation and new role
>
> One can always write a validation document that considers the role, no? Why
> can't users who need this functionality craft a validation function for this
> purpose? This sounds like a blog post and not a database feature.
>
> +0 on _dump/_load
>
> If it ships raw .couch files I'm totally against it because I think the HTTP
> API should remain as independent of implementation details as possible. If
> it is non-incremental I don't see significant benefit, unless it's just to
> traverse the document index and ignore the sequence index as a way to skip
> reads, but this seems like a weak argument. If it's incremental, well, then,
> that's replication, and we already have that.
>

Think of plain text backups and last resort upgrade paths. Also, it
wouldn't have validation docs run on it  or anything of that nature.
I'm thinking basically of having a multipart/mime stream
representation of the database that follows the update sequence. And
the _dump would allow for a ?since= parameter that would make it
incremental. This would even give people the ability to do daily logs
and so on.

> -Randall
>
>
> On Tue, Aug 16, 2011 at 11:40, Adam Kocoloski <kocolosk@apache.org> wrote:
>
>> Hi Jean-Pierre, I'm not quite sure I follow that line of reasoning.  A user
>> with _admin privileges on the database can easily remove any validation
>> functions prior to writing today.  In my proposal skipping validation would
>> require _admin rights and an explicit opt-in on a per-request basis.  What
>> are you trying to guard against with those validation functions?  Best,
>>
>> Adam
>>
>> On Aug 16, 2011, at 2:29 PM, Jean-Pierre Fiset wrote:
>>
>> > I understand the issue brought by Adam since in our CouchDb application,
>> there is a need to have a replicator role and the validation functions skip
>> most of the tests if the role is set for the current user.
>> >
>> > On the other hand, at the current time, I am not in favour of making
>> super users for the sake of replication. Although it might solve the
>> particular problem stated, it removes the ability for a design document to
>> enforce some "invariant" properties of a database.
>> >
>> > Since there is already a way to allow a "replicator" to perform any
>> changes (role + proper validation function), I do not see the need for this
>> change. Since the super replicator user removes the ability that a database
>> has to protect the consistency of its data, and that there does not seem to
>> be a work-around, I would rather not see this change pushed to CouchDb.
>> >
>> > JP
>> >
>> > On 11-08-16 10:26 AM, 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
>> >
>>
>>
>

Mime
View raw message