I think that the operations of replication and backing up are quite different. Although some are using the replication features for backing up, I tend to think of replication as an operation taking place between two nodes that do not necessarily trust one another.
If what you are proposing is a special privilege given to the admin party, then I do not have much of an issue with this, since administrators already have intimate access to the server. However, the concept of creating a new "replicator" role, which would supersede the validation functions is another thing. In applications that must ensure that some document types have a given structure, opening the door to a user (and here I assume a user that attempts a replication from a different node, not a local administrator performing a back up) to work around the validation function is probably a bad idea. If the validation function could not be counted on, it would really affect the way an application must be written. JP On 11-08-16 02:40 PM, 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 >> >
