incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hahn <m...@boutiquing.com>
Subject Re: conflict determination not by fields
Date Wed, 31 Aug 2011 19:14:02 GMT
If it is impossible to resolve the conflict without previous versions,
then it would be forced to return undefined.

The problem of not having information about what changed is a big
problem in couch even when the app is doing the conflict resolution.

On Wed, Aug 31, 2011 at 12:09 PM, Jens Alfke <jens@couchbase.com> wrote:
>
> On Aug 31, 2011, at 11:58 AM, Mark Hahn wrote:
>
> It would have to be guaranteed to give the same results on all
> servers.  This is the same condition the current couch has.  It would
> effectively be replacing the current algorithm unless it returns
> undefined.
>
> That would be tricky if it were trying to merge changed fields. Determining whether a
field changed relies on comparing its value to the previous revision, but “previous revision”
isn’t a well-defined concept in CouchDB*. So if two nodes have differing sets of prior revisions,
they might come to different conclusions about which fields changed, resulting in different
merges.
>
> —Jens
>
> * Or that’s my impression; I might be wrong. My understanding is that, unlike a VCS,
CouchDB doesn’t store the parent revision ID in a document, so there’s no explicit tree
of revisions. And anyway there’s no guarantee that an earlier revision still exists, since
they all get removed during compaction. Someone let me know if this is inaccurate.
>

Mime
View raw message