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 <nate-li...@calftrail.com> 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 <j...@apache.org> 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 <kocol...@apache.org> 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 >>>> >>>> >>
