Hmm, if we used a separate role we'd need a multi-step process to trigger the replication
1) create the database 2) have an admin grant the _skip_validation role on that DB to the replicator's user_ctx 3) trigger the replication Kind of annoying. Certainly would be simpler to allow _admins to do this if just by adding a skip_validation=true parameter to write requests. Adam On Aug 16, 2011, at 2:21 PM, Robert Newson wrote: > no objection to special role. As in my opening statement, would be > concerned about adding it to _admin without devoting more thought to > possible unintended consequences. > > b. > > On 16 August 2011 19:13, Robert Dionne <[email protected]> wrote: >> No objection, just the question of why the need for a new role, why not use >> admin? >> >> >> >> On Aug 16, 2011, at 2:10 PM, Adam Kocoloski wrote: >> >>> Wow, this thread got hijacked a bit :) Anyone object to the special role >>> that has the "skip validation" superpower? >>> >>> Adam >>> >>> On Aug 16, 2011, at 1:51 PM, Jan Lehnardt wrote: >>> >>>> Both rsync an scp won't allow me to do curl http://couch/db/_dump | curl >>>> http://couch/db/_restore. >>>> >>>> I acknowledge that similar solutions exist, but using the http transport >>>> allows for more fun things down the road. >>>> >>>> See what we are doing with _changes today where DbUpdateNotifications >>>> nearly do the same thing. >>>> >>>> Cheers >>>> Jan >>>> -- >>>> >>>> On 16.08.2011, at 19:13, Nathan Vander Wilt <[email protected]> >>>> wrote: >>>> >>>>> We've already got replication, _all_docs and some really robust on-disk >>>>> consistency properties. For shuttling raw database files between servers, >>>>> wouldn't rsync be more efficient (and fit better within existing sysadmin >>>>> security/deployment structures)? >>>>> -nvw >>>>> >>>>> >>>>> On Aug 16, 2011, at 9:55 AM, Paul Davis wrote: >>>>>> Me and Adam were just mulling over a similar endpoint the other night >>>>>> that could be used to generate plain-text backups similar to what >>>>>> couchdb-dump and couchdb-load were doing. With the idea that there >>>>>> would be some special sauce to pipe from one _dump endpoint directly >>>>>> into a different _load handler. Obvious downfall was incremental-ness >>>>>> of this. Seems like it'd be doable, but I'm not entirely certain on >>>>>> the best method. >>>>>> >>>>>> I was also considering this as our full-proof 100% reliable method for >>>>>> migrating data between different CouchDB versions which we seem to >>>>>> screw up fairly regularly. >>>>>> >>>>>> +1 on the idea. Not sure about raw couch files as it limits the wider >>>>>> usefulness (and we already have scp). >>>>>> >>>>>> On Tue, Aug 16, 2011 at 10:24 AM, Jan Lehnardt <[email protected]> wrote: >>>>>>> This is only slightly related, but I'm dreaming of /db/_dump and >>>>>>> /db/_restore endpoints (the names don't matter, could be one with GET / >>>>>>> PUT) that just ships verbatim .couch files over HTTP. It would be for >>>>>>> admins only, it would not be incremental (although we might be able to >>>>>>> add that), and I haven't yet thought through all the concurrency and >>>>>>> error case implications, the above solves more than the proposed >>>>>>> problem and in a very different, but I thought I throw it in the mix. >>>>>>> >>>>>>> Cheers >>>>>>> Jan >>>>>>> -- >>>>>>> >>>>>>> On Aug 16, 2011, at 5:08 PM, Robert Newson wrote: >>>>>>> >>>>>>>> +1 on the intention but we'll need to be careful. The use case is >>>>>>>> specifically to allow verbatim migration of databases between servers. >>>>>>>> A separate role makes sense as I'm not sure of the consequences of >>>>>>>> explicitly granting this ability to the existing _admin role. >>>>>>>> >>>>>>>> B. >>>>>>>> >>>>>>>> On 16 August 2011 15:26, Adam Kocoloski <[email protected]> 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 >>>>>>> >>>>>>> >>>>> >>> >> >>
