"all_or_nothing":true continues to work in couchdb 2.0. The semantic for all_or_nothing: true changed just before couchdb 1.0 came out to allow it to work in a (future) cluster. Instead of a true all-or-nothing, what happens instead is that conflicts are introduced if necessary.
A side-effect of a couchdb database being a single file meant that a bulk_docs write would also be atomic, this does not hold in 2.0 (though it holds at the shard level, which is no help to you at all). Personally, I think we should remove the option entirely, it doesn’t really do what the name implies, and it cannot be made to do so, but it works about the same in 2.0 as it did in 1.0, for what that’s worth. B. > On 15 May 2015, at 11:05, Dale Harvey <[email protected]> wrote: > > Those steps look remarkably similiar to how the replicator works, wondering > why you arent using that? > > [email protected] wrote: >> Thanks for your suggestion, >> >> I'll just write my steps here to benefit other users that wants >> all_or_nothing in v2.0: >> 1. For each docs: >> - retrieve _revisions using GET /db/doc?rev=latest_rev&revs=true >> - generate new revision ID (I use HMAC here), prepend it to _revisions.ids >> - increase _revisions.start >> 2. POST bulk_docs with new_edits:false >> >> It works, but feels very hackish as there are now n requests (one for each >> doc) to get >> _revisions instead of only one all_or_nothing. >> >> I assume the difficulty of all_or_nothing in v2.0 comes multi-master and >> having >> to rollback multiple docs on validation failure. >> >> So I suggest something simpler like: PUT /db/doc?rev=latest_rev&force=true >> that always return success. Developers can then loop on each document to >> mimic >> previous bulk_docs semantic. >> Seems possible to me, but I don't understand CouchDB internals. >> >> Thanks for your help :) >> >> -------------------------------------------- >> On Fri, 15/5/15, Alexander Shorin <[email protected]> wrote: >> >> Subject: Re: How to 'force write' in v2.0 ? >> To: [email protected] >> Cc: "[email protected]" <[email protected]> >> Date: Friday, 15 May, 2015, 2:51 >> >> On Thu, May 14, 2015 at >> 10:22 PM, Peter Norwich >> <[email protected]> >> wrote: >>>>> So your case if about >> just blindly push bulk docs from time to time and not care >> about any conflicts they may produce? >>> >>> No. My case in >> detail: >>> - client modify doc during >> offline >>> - when online, client sync with >> server (this used to be _bulk_docs all_or_nothing) >>> write should always be >> succesful, so that offline change won't be lost >>> - server returns winning rev along with >> all possible conflicts >>> - client resolve >> conflicts manually >>> - client save the >> latest _rev for next sync. >>> >>> tldr: write always success, read returns >> all conflicts. >>> See this proposal >> written 3 years ago https://gist.github.com/rnewson/2387973 >>> Point number 1 is exactly what I need. >> >> all_or_nothing couldn't be >> implemented as we can promise no more >> semantic that lies behind it. >> >> So what could you do: >> - use _bulk_docs with new_edits: false >> introducing conflicts. For the >> new docs >> required _rev replace with dummy uuid; >> - >> wait for merge or apply manually >> https://github.com/apache/couchdb-chttpd/pull/33 >> patch in order to >> fetch all conflicts in >> bulk (as you know all your docs ids); >> - >> proceed with your old logic as you have now all the revs and >> all the >> conflicts. >> >> Not sure if Point number 1 from referenced >> approach will be in 2.0, >> but so far it is >> not. >> >> -- >> ,,,^..^,,, >> > > -- > Sent Using Firefox OS
