On Tue, Aug 16, 2011 at 4:46 PM, Randall Leeds <[email protected]> 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 <[email protected]> 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 >> > >> >> >
