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 >
