couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jamie Talbot <ja...@jamietalbot.com>
Subject Re: Differing responses for retrieving a deleted document through GET and POST
Date Sat, 08 Oct 2011 03:20:53 GMT
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 <max@maxogden.com> 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 <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
>>
>



-- 
---
http://jamietalbot.com

Mime
View raw message