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
