[
https://issues.apache.org/jira/browse/COUCHDB-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13843730#comment-13843730
]
Dale Harvey commented on COUCHDB-1950:
--------------------------------------
So the problem being that in a system where we manage to get conflicts to
happen simultaneously on seperate nodes, instead of having a 3 way merge with
the original documents, this will result in a 2 way merge of the result of the
'resolved' documents (potentially lost information). That is entirely true of
how we currently document how conflict resolution should be done now.
There isnt a problem with this suggestion per se, more that its just exposing
what is already a 'flaw' in the current documented implementation.
A read resolver would be a much easier / safer thing to implement, however it
comes with its own problems, to make a read resolver any way API consistent
between all_docs / views / changes etc will mean a huge increase in the number
of disk fetches each api call has to make, as it now needs to fetch each
conflicting document and run them through a view engine
Currently we hide all these complexities behind the winning revision mechanism,
this is hiding what most people to consider CouchDB's killer feature so I do
think its worth figuring out how to get it right
> 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)
