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