couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
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 <> 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 <> 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
>> >

View raw message