couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <rnew...@apache.org>
Subject Re: Eventual Consistency
Date Mon, 31 Mar 2014 10:02:41 GMT
Exactly. It’s when a document is updated at two different couchdb servers, in two different
ways, and then the two replicate to each other. Eventual consistency is the term used for
the algorithm that ensures both sites, after replicating in both directions, show the same
revision (and know both divergent changes).

B.

On 31 Mar 2014, at 09:16, Florian Westreicher Bakk.techn. <stuff@meredrica.org> wrote:

> 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 <amirhos.hajiz@gmail.com>
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.


Mime
View raw message