Sorry, I had originally intended to suggest a 203 not a 202. I agree, it’s a stretch to find a status code the matches exactly to the meaning. I think 203 Non-Authorative is closest. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.4
</JamesM> On Mar 25, 2015, at 5:03, Robert Newson <[email protected]> wrote: > Also noting that there's no status code in the standard to indicate what we > mean by 202 for a write for GET. > > Sent from my iPhone > >> On 25 Mar 2015, at 04:49, Robert Newson <[email protected]> wrote: >> >> 2.0 is explicitly an AP system, the behaviour you describe is not classified >> as a bug. >> >> Anti-entropy is the main reason that you cannot get strong consistency from >> the system, it will transform "failed" writes (those that succeeded on one >> node but fewer than R nodes) into success (N copies) as long as the nodes >> have enough healthy uptime. >> >> True of cloudant and 2.0. >> >> Sent from my iPhone >> >>> On 24 Mar 2015, at 15:14, Mutton, James <[email protected]> wrote: >>> >>> Funny you should mention it. I drafted an email in early February to queue >>> up the same discussion whenever I could get involved again (which I >>> promptly forgot about). What happens currently in 2.0 appears unchanged >>> from earlier versions. When R is not satisfied in fabric, >>> fabric_doc_open:handle_message eventually responds with a {stop, …} but >>> leaves the acc-state as the original r_not_met which triggers a read_repair >>> from the response handler. read_repair results in an {ok, …} with the only >>> doc available, because no other docs are in the list. The final doc >>> returned to chttpd_db:couch_doc_open and thusly to chttpd_db:db_doc_req is >>> simply {ok, Doc}, which has now lost the fact that the answer was not >>> complete. >>> >>> This seems straightforward to fix by a change in >>> fabric_open_doc:handle_response and read_repair. handle_response knows >>> whether it has R met and could pass that forward, or allow read-repair to >>> pass it forward if read_repair is able to satisfy acc.r. I can’t speak for >>> community interest in the behavior of sending a 202, but it’s something I’d >>> definitely like for the same reasons you cite. Plus it just seems >>> disconnected to do it on writes but not reads. >>> >>> Cheers, >>> </JamesM> >>> >>>> On Mar 24, 2015, at 14:06, Nathan Vander Wilt <[email protected]> >>>> wrote: >>>> >>>> Sorry, I have not been following CouchDB 2.0 roadmap but I was extending >>>> my fermata-couchdb plugin today and realized that perhaps the Apache >>>> release of BigCouch as CouchDB 2.0 might provide an opportunity to fix a >>>> serious issue I had using Cloudant's implementation. >>>> >>>> See https://github.com/cloudant/bigcouch/issues/55#issuecomment-30186518 >>>> for some additional background/explanation, but my understanding is that >>>> Cloudant for all practical purposes ignores the read durability parameter. >>>> So you can write with ?w=N to attempt some level of quorum, and get a 202 >>>> back if that quorum is unment. _However_ when you ?r=N it really doesn't >>>> matter if only <N nodes are available…if even just a single available node >>>> has some version of the requested document you will get a successful >>>> response (!). >>>> >>>> So in practice, there's no way to actually use the quasi-Dynamo features >>>> to dynamically _choose_ between consistency or availability — when it >>>> comes time to read back a consistent result, BigCouch instead just always >>>> gives you availability* regardless of what a given request actually needs. >>>> (In my usage I ended up treating a 202 write as a 500, rather than >>>> proceeding with no way of ever knowing whether a write did NOT ACTUALLY >>>> conflict or just hadn't YET because $who_knows_how_many nodes were still >>>> down…) >>>> >>>> IIRC, this was both confirmed and acknowledged as a serious bug by a >>>> Cloudant engineer (or support personnel at least) but could not be quickly >>>> fixed as it could introduce backwards-compatibility concerns. So… >>>> >>>> Is CouchDB 2.0 already breaking backwards compatibility with BigCouch? If >>>> true, could this read durability issue now be fixed during the merge? >>>> >>>> thanks, >>>> -natevw >>>> >>>> >>>> >>>> >>>> >>>> * DISCLAIMER: this statement has not been endorsed by actual uptime of >>>> *any* Couch fork… >>>
