couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jamie Talbot <>
Subject Differing responses for retrieving a deleted document through GET and POST
Date Sat, 08 Oct 2011 02:02:24 GMT

I was wondering about what I think is an inconsistency in how
searching works for documents that have been deleted.  Having deleted
a document, it no longer appears in _all_docs, as expected.  A GET to
the document URL return 404 as expected.  However, POSTing the _id in
'keys' to _all_docs still returns a document with 200, albeit with
deleted: true.  Sample steps to reproduce are below:

majelbstoat@Neptune~ $ curl -X POST http://localhost:5984/dummy/ -H
"Content-Type: application/json" -d "{\"_id\": \"1234\", \"name\":
majelbstoat@Neptune~ $ curl -X POST http://localhost:5984/dummy/ -H
"Content-Type: application/json" -d "{\"_id\": \"5678\", \"name\":
majelbstoat@Neptune~ $ curl -X DELETE
majelbstoat@Neptune~ $ curl -X GET http://localhost:5984/dummy/_all_docs
majelbstoat@Neptune~ $ curl -X POST
http://localhost:5984/dummy/_all_docs -H "Content-Type:
application/json" -d "{\"keys\": [\"1234\"]}"
majelbstoat@Neptune~ $ curl -X GET http://localhost:5984/dummy/1234

Is this a deliberate design decision, and if so is there a particular
reason for this?  I've been relying heavily on the use of HTTP status
codes, and receiving 404 in one context and 200 in another is what
confuses me.  I can of course rewrite the logic to check for a
'deleted' key, but decoding the data to do so is less elegant and more
intensive than just observing the response status.  Unfortunately at
the moment I have consider all 200 responses suspect, which rather
diminishes its usefulness for me.

(Version 1.1.0, OSX through Macports).




View raw message