couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: The replicator needs a superuser mode
Date Tue, 16 Aug 2011 18:40:09 GMT
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,


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