>> I would recommend you to use your own field for tracking ancestry and >> relations and not generate rev manually
I don't see how it's possible to do this since new_edits:false expects existing revision ID. and there is no API to just ask CouchDB to generate rev for a doc. I see previous discussion "Making conflict first class citizens" (http://grokbase.com/t/couchdb/user/124jegc8kn/making-conflicts-first-class-citizens) Does anyone know what is the conclusion ? It seems to be *exactly* what I need. But I don't see how to do that now in 2.0. new_edits:false seems too convoluted for what seems to be a simple task. It's essentially asking developer to write CouchDB replicator (like PouchDB), but my use case is just a lightweight desktop client (with no knowledge of server DB), pushes the doc, and resolve resulting conflict manually. -------------------------------------------- On Thu, 14/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: Thursday, 14 May, 2015, 22:17 On Thu, May 14, 2015 at 5:40 PM, Peter Norwich <[email protected]> wrote: >>> all_or_nothing doesn't introduces conflicts. > > You mean it's the new behavior in 2.0 ? in 1.6 all_or_nothing will happily write and introduce conflicts > as long as it pass validation. > No, it's not new. new_edits: false is how replicator sync databases introducing conflicts. But you're right about all_or_nothing behaviour: sets a merge_conflicts option which introduces conflicts as well during rev tree merge: https://github.com/apache/couchdb/blob/1.6.1/src/couchdb/couch_db.erl#L757-L790 https://github.com/apache/couchdb/blob/1.6.1/src/couchdb/couch_db_updater.erl#L627-L630 >>> For introducing conflicts, use new_edits: false > > I tried, but then the client has to generate rev manually and keep track all parents' revisions all the > way until revpos 1. Is there simpler solution ? > Does the request needs to list all parents rev or only the latest one ? I tried both and its successful. > e.g.: > _revisions":{"start":4,"ids":["3595405","877727288","376647","28839289"]} > _revisions":{"start":4,"ids":["3595405","877727288"]} > > what is the implication of supplying only the latest rev ? I would recommend you to use your own field for tracking ancestry and relations and not generate rev manually - this way more opaque for you and you're not goes in conflict with CouchDB internals. -- ,,,^..^,,,
