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…
