[
https://issues.apache.org/jira/browse/COUCHDB-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13843167#comment-13843167
]
Jan Lehnardt commented on COUCHDB-1950:
---------------------------------------
I am suggesting moving a bit of user code from the app to the ddoc. It is still
user code and codifies user-intent, so I’d be happy for it to properly resolve
a conflict by picking a winning revision over others, like an app does today.
There need to be a few limits on resolution functions, like we have for map
functions, but I think that is entirely reasonable.
I’d be happy to make this an opt-in plugin, but my crystal ball says that it
will quickly be the most installed plugin :)
> 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)
