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