couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Marshall <omarsh...@facilityone.com>
Subject Re: Peer-to-Peer Replication
Date Wed, 06 Apr 2011 21:21:59 GMT
On 04/06/2011 04:24 PM, Zdravko Gligic wrote:

> *snip*

I've got the gut feeling based on your questions that you want us to be
telling you about clustering :) Do note that clustering is orthogonal to
replication.

What exactly are you wanting to accomplish here?

>> CouchDB doesn't ensure that the latest revision wins -- you are expected
>> to resolve conflicts in a way that makes sense for your application.
> 
> I understand this in context of revisions to a single document.
> However, I was more curious about how it internally determined which
> of 2 arbitrary peers had a more recent and up to date copy.

Whichever document has the largest _rev count is the most recent.

Thus, "2-2a3c(...)" will win over "1-a41b(...)" because 2 > 1.

If however a node encounters a two different documents with the same
_rev count, as such:

> D._rev = "2-23863ae70f0e2477e9ea3664b38eab4b"
> D'._rev = "2-b967c531a44dd2887fb4d51c35003476"

CouchDB will pick the revision with the highest UUID component (D').

This is merely to ensure consistency of documents. It says nothing about
whether or not D' was better than D, nor does it try to merge D into D',
etc. Put simply, your application *must not* rely on _rev. It's only for
CouchDB replication.

Instead, your application should watch for conflicts ("_conflicts":true)
and handle them in whatever way makes sense.

As an example: one part of an application may walk through every
conflict and merge it back into a new revision, running everything
through some business logic and possibly creating intermediate states --
and for other parts, you might just keep the winning message and discard
the others. It all depends on what _you_ need.

-- 
Owen Marshall
FacilityONE
omarshall@facilityone.com | (502) 805-2126


Mime
View raw message