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. -- ,,,^..^,,,
