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…
