You only have eventual consistency when you use more than one instance of couch and replication, because the write needs to be replicated to the second instance.
You are responsible to fix conflicts yourself and CouchDB will happily tell you where conflicts are. The way they are 'solved' the in couch before you get a go at it is that a winning version is chosen on every node that is guaranteed to be the same everywhere. On March 31, 2014 6:19:11 AM CEST, Amir Hossein Hajizadeh <[email protected]> wrote: >Hi, > >First, please let me know if I'm posting it in a wrong place. > >My question is, how does CouchDB claims that it has "eventual >consistency" while the records in it have "_rev" field? For now I've >learned that if you don't have the latest _rev field CouchDB doesn't >allow you to update the record, complaining that there's a conflict. > >So, can you give me an example of a scenario when CouchDB shows the >behaviour of "eventual consistency"? In that scenario, what if there is > >eventually a conflict? Who will be responsible to resolve it? > >Thanks, >Amir Hossein Hajizadeh -- Sent from Kaiten Mail. Please excuse my brevity.
