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
