hello, _all_docs is a "bulk" api which means that it is built to treat its responses with plurality. this means that the HTTP status code refers not to the documents but rather the "container" array that you get back.
you requested all the docs matching some arbitrary set of ids and couch responds by saying "ok, got all those docs, here ya go" and sends the docs along with a 200 since the request executed correctly. you can either parse the JSON in your app or use non-bulk APIs if you want to rely solely on the status codes On Fri, Oct 7, 2011 at 7:02 PM, Jamie Talbot <[email protected]> wrote: > Hi, > > 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\": > \"monkey\"}" > {"ok":true,"id":"1234","rev":"1-4f1a0c4ebfe937f06161d7c3d90f5cff"} > majelbstoat@Neptune~ $ curl -X POST http://localhost:5984/dummy/ -H > "Content-Type: application/json" -d "{\"_id\": \"5678\", \"name\": > \"magic\"}" > {"ok":true,"id":"5678","rev":"1-c924380de3517764a68af46a07b5fe6f"} > majelbstoat@Neptune~ $ curl -X DELETE > http://localhost:5984/dummy/1234?rev=1-4f1a0c4ebfe937f06161d7c3d90f5cff > {"ok":true,"id":"1234","rev":"2-2e793b782be7d156372200c5878910dc"} > majelbstoat@Neptune~ $ curl -X GET http://localhost:5984/dummy/_all_docs > {"total_rows":1,"offset":0,"rows":[ > > {"id":"5678","key":"5678","value":{"rev":"1-c924380de3517764a68af46a07b5fe6f"}} > ]} > majelbstoat@Neptune~ $ curl -X POST > http://localhost:5984/dummy/_all_docs -H "Content-Type: > application/json" -d "{\"keys\": [\"1234\"]}" > {"total_rows":1,"offset":0,"rows":[ > > {"id":"1234","key":"1234","value":{"rev":"2-2e793b782be7d156372200c5878910dc","deleted":true}} > ]} > majelbstoat@Neptune~ $ curl -X GET http://localhost:5984/dummy/1234 > {"error":"not_found","reason":"deleted"} > > 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). > > Cheers, > > Jamie. > > --- > http://jamietalbot.com >
