MOVE is gone and staying gone, because it's not atomic. COPY, then DELETE.
http://wiki.apache.org/couchdb/HTTP_Document_API#COPY B. On 8 March 2013 09:16, Bruno Rohée <[email protected]> wrote: > The way you plan to implement a move operation after this feature would be > a recipe for data loss (what if the client crashes after the delete) > > If there are no use for this beyond moving docs, re-implementing > http://tools.ietf.org/html/rfc2518#section-8.9 (WebDAV MOVE method) would > gain everyone much more... It existed, was removed before 0.9, it possibly > could be remade... > > > On Fri, Mar 8, 2013 at 3:46 PM, Benjamin Young (JIRA) <[email protected]>wrote: > >> Benjamin Young created COUCHDB-1688: >> --------------------------------------- >> >> Summary: Add query param for returning document on DELETE >> Key: COUCHDB-1688 >> URL: https://issues.apache.org/jira/browse/COUCHDB-1688 >> Project: CouchDB >> Issue Type: Improvement >> Components: HTTP Interface >> Reporter: Benjamin Young >> >> >> This would simplify "move" operations by lowering the number of "trips" to >> the server. >> >> (pseudo HTTP below) >> >> DELETE /db/test_doc?rev=1-whatever&include_doc=true >> >> 200 OK >> {"ok":true,"id":"test_doc","rev":"6-9663bc6a92dc87488a3bf036cd7f8b2f", >> "doc": {"test":"JSON", "type":"testing"}} >> >> With the full doc available in the doc key in the DELETE response, the >> developer could simply pull out the value of doc (modify it if needed), and >> PUT it back somewhere else. >> >> Currently, this "flow" looks more like this: >> >> GET /db/test_doc >> # keep doc in memory/cache in the app >> DELETE /db/test_doc?rev=1-whatever >> PUT /db/new_doc_location >> # use doc from memory/cache in app >> >> Maybe a "nice to have" but it would be nice to have. :) >> >> -- >> This message is automatically generated by JIRA. >> If you think it was sent incorrectly, please contact your JIRA >> administrators >> For more information on JIRA, see: http://www.atlassian.com/software/jira >>
