couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1950) ddoc-based conflict resolution
Date Mon, 09 Dec 2013 14:44:08 GMT


Robert Newson commented on COUCHDB-1950:

What I think we *can* safely do is;

function(leafs) {
  leafs.sort(function(a,b) { return b.last_updated - a.last_updated });
  return leafs[0];    

so that instead of our winner algorithm, the user would see some semantically 'latest' version
(a bit like Riak, I think?). That function isn't perfectly deterministic, of course, two leafs
could have identical last_updated values, but the user (well, app developer) would understand
that. More importantly, only resolving on read will not impact eventual consistency or cause
replicator-induced edit cycles.

As to how we could automate the removal of losing edit branches (or even the removal of deleted
branches), I don't know if there is a perfect answer. An imperfect one, that I hesitate to
even mention, would be wall clock-based. A user could tell couchdb to only keep losing branches
for a certain period of time, after which it may assume that the update has been replicated
everywhere. The duration chosen for this will be app-specific, of course. At Cloudant, for
the conflicts that are generated wholly within the system, as opposed to the ones from users,
we might set that at a few hours or even less. In general, no value is guaranteed to be safe.
I would not like to see such a thing in core, though.

> ddoc-based conflict resolution
> ------------------------------
>                 Key: COUCHDB-1950
>                 URL:
>             Project: CouchDB
>          Issue Type: Improvement
>            Reporter: Nathan Vander Wilt
> This was discussed at CouchConf in Vancouver last month, but didn't see a hook here I
could refer to in another conversation, so…
> It'd be great if a design document could include a conflict resolver function, in the
vein of other "app logic" handler hooks like validate_doc_write. I imagine it would look something
like either "function (currentWinner, nextWinningestLoser, parent)" (simply called multiple
times if more than 2 leafs) or simply "function (arrayOfDocs, revisionHistor)" — if it returns
a document, that's the winner, if not the next design document in line gets a pass at it.
(Bonus: if it throws, the conflict stays no matter what other resolvers say?)

This message was sent by Atlassian JIRA

View raw message