couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dale Harvey (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1950) ddoc-based conflict resolution
Date Tue, 10 Dec 2013 00:02:07 GMT


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

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

View raw message