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