Hey, Appreciate the response. That does make sense - it's just a shame I have to do that extra step each time, while being able to rely on status codes everywhere else. (In this particular scenario, sometimes I will have multiple ids, sometimes only one, so the bulk API is the simplest way to handle all cases.) I had a look to see if I could find what I would consider a better response code, but aside from 410 for 'none found' or 206 for 'some found', neither of which are particularly clear, so I'm not really sure what I'd even want :) 200 it is!
Best, Jamie. On Sat, Oct 8, 2011 at 12:37, Max Ogden <[email protected]> wrote: > 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 >> > -- --- http://jamietalbot.com
