`new_edits` is a boolean option to pass as query parameters for a PUT or BULK_DOCS operation. It is meant to be used by replicators only. I am writing a replicator! So I ought to use it. Then it costed me a day to learn what it really means and what are expected from it. Needless to say, since writing a replicator is not a common thing to do, the documentation about it is lacking. I am quite ready to be confused, and then I was today.
First minor confusion: this flag is default to be `true`. To force CouchDB to accept the document as-is, ultimately the `rev` will not cause any complaint, this flag need to set as `false`. `new_edits` is actually the correct term. In normal time, `PUT` are usually a new edition of the document. But for CouchDB to verify this PUT is legit, the `rev` need to match the latest winning document. A legit normal PUT should have a document with new content, old rev and `new_edits=true`.
Then, as replicators, we need to deliberately create a conflicting document. `new_edits=false` is the way to let us do that. The dumber me in the morning thought passing this `new_edit=false` with my document will tell CouchDB to give me a new rev, by passing it the same old rev again. But CouchDB kept giving me back the same old rev in the response, instead of a new rev that generate by CouchDB.
Typing this really show how dumb I was. As replicators, we had the document with the wrong rev already! And expecting CouchDB to generate a new rev for a conflicting document is unreasonable!
A force PUT to deliberately creating a conflict should have a document with another content, a previously generated rev in another DB and `new_edits=false`.
First minor confusion: this flag is default to be `true`. To force CouchDB to accept the document as-is, ultimately the `rev` will not cause any complaint, this flag need to set as `false`. `new_edits` is actually the correct term. In normal time, `PUT` are usually a new edition of the document. But for CouchDB to verify this PUT is legit, the `rev` need to match the latest winning document. A legit normal PUT should have a document with new content, old rev and `new_edits=true`.
Then, as replicators, we need to deliberately create a conflicting document. `new_edits=false` is the way to let us do that. The dumber me in the morning thought passing this `new_edit=false` with my document will tell CouchDB to give me a new rev, by passing it the same old rev again. But CouchDB kept giving me back the same old rev in the response, instead of a new rev that generate by CouchDB.
Typing this really show how dumb I was. As replicators, we had the document with the wrong rev already! And expecting CouchDB to generate a new rev for a conflicting document is unreasonable!
A force PUT to deliberately creating a conflict should have a document with another content, a previously generated rev in another DB and `new_edits=false`.