Sounds like a thug. But, no pain, no gain. Yo!
Conflict is the way of CouchDB, and life. Embracing it with love is how we live in harmony, with Database, and with people too. To learn to embrace CouchDB's conflict, one must first create it in a control environment, then slowly exposing it to the system for adaptation. a.k.a. test driven development.
Creation of conflict, intended, was supposed to be an easy job. Though, for me, it took a few days of tinkering to find out. That's my previous post about `new_edits`. Today, I masterfully create conflicts in my unit test with the very same `new_edits` in my `put` API. The single changes I need to make is start creating revision string manually and use that revision string instead of the automatic one by CouchDB. CouchDB's put API will turn a blind eye on the `rev` of my document when I use `new_edits=false`.
So, I created one version of the document with a normal put. Then create another document with my manual revision string and `put` with `new_edits=false`. Boom. I created a conflict intentionally. I just need an official way to verify the conflict to pass my tests.
Here come a new `get` option: `conflicts=true`. Passing this extra option in my usual get will add a new `conflicts` array into my responded document. Just like `_id` and `_rev`, `_conflicts` and build in property to any CouchDB document. When a conflict happened with a document, the `_conflicts` array will contain the revision String of all other leaf revisions. Checking this list is a good way to tell if the conflict happened, and which revisions are there.
Conflict is the way of CouchDB, and life. Embracing it with love is how we live in harmony, with Database, and with people too. To learn to embrace CouchDB's conflict, one must first create it in a control environment, then slowly exposing it to the system for adaptation. a.k.a. test driven development.
Creation of conflict, intended, was supposed to be an easy job. Though, for me, it took a few days of tinkering to find out. That's my previous post about `new_edits`. Today, I masterfully create conflicts in my unit test with the very same `new_edits` in my `put` API. The single changes I need to make is start creating revision string manually and use that revision string instead of the automatic one by CouchDB. CouchDB's put API will turn a blind eye on the `rev` of my document when I use `new_edits=false`.
So, I created one version of the document with a normal put. Then create another document with my manual revision string and `put` with `new_edits=false`. Boom. I created a conflict intentionally. I just need an official way to verify the conflict to pass my tests.
Here come a new `get` option: `conflicts=true`. Passing this extra option in my usual get will add a new `conflicts` array into my responded document. Just like `_id` and `_rev`, `_conflicts` and build in property to any CouchDB document. When a conflict happened with a document, the `_conflicts` array will contain the revision String of all other leaf revisions. Checking this list is a good way to tell if the conflict happened, and which revisions are there.