incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Copenhaver <>
Subject Re: conflict determination not by fields
Date Wed, 31 Aug 2011 12:35:56 GMT
Well might be better to have it return the winning doc (with or without
modifications to allow manual merging) or null/undefined if CouchDB should
use it's usual resolution of marking them as in conflict and picking the one
with the highest revision hash.

This does sound like a nice feature, something like:

resolve: function (doc1, doc2) {}

in a design doc? Of course then what happens with multiple, first one to
return a non-falsy value wins?

On Wed, Aug 31, 2011 at 3:48 AM, Mark Hahn <> wrote:

> >  the script has to be allowed to give up
> Sure.  It could return the winning _id or undefined.
> On Wed, Aug 31, 2011 at 12:24 AM, Jens Alfke <> wrote:
> >
> > On Aug 30, 2011, at 11:55 PM, Mark Hahn wrote:
> >
> > I want the feature of having a script to resolve the conflicts.  That
> > feature never occurred to me before.  It would be similar in function
> > to an update script.
> >
> > That could be useful, except that the script has to be allowed to give
> up, since some conflicts can’t be resolved without user intervention. (Or at
> least, without higher-level work than can be done in a callback function
> running inside the database server.)
> >
> > —Jens
> >
> >

“The limits of language are the limits of one's world. “ - Ludwig von

"Water is fluid, soft and yielding. But water will wear away rock, which is
rigid and cannot yield. As a rule, whatever is fluid, soft and yielding will
overcome whatever is rigid and hard. This is another paradox: what is soft
is strong." - Lao-Tzu

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message