[ https://issues.apache.org/jira/browse/COUCHDB-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13843195#comment-13843195 ]
Jan Lehnardt commented on COUCHDB-1950: --------------------------------------- What then, is our story for app-level resolution functions? A _changes-feed powered app-level-resolver will create the same issues as far as I can tell and I am happy to use a different thing altogether. Whatever we suggest that people do in their apps, I’d like to take a piece out of the boilerplate that they need to set up for running CouchDB apps. (I hope that clarifies my motivation). > 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)