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 >>>>> >>>>> >>> >
