[
https://issues.apache.org/jira/browse/COUCHDB-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13843208#comment-13843208
]
Robert Newson commented on COUCHDB-1950:
----------------------------------------
What I think we *can* safely do is;
"read_resolve":
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: https://issues.apache.org/jira/browse/COUCHDB-1950
> 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
(v6.1.4#6159)
