couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Ogden <...@maxogden.com>
Subject Re: Differing responses for retrieving a deleted document through GET and POST
Date Sat, 08 Oct 2011 02:37:47 GMT
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 <jamie@jamietalbot.com> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message