couchdb-dev mailing list archives

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

    [ https://issues.apache.org/jira/browse/COUCHDB-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13843164#comment-13843164
] 

Robert Newson commented on COUCHDB-1950:
----------------------------------------

I am saying that couchdb has a firm principle of not discarding a user's write, and it is
that excellent principle I am defending here.

Allowing customisation of which of the leafs is presented as the winner sounds fine (assuming
the code is deterministic).

Which of these two different meanings of "resolve" is this ticket about?


> 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)

Mime
View raw message