[
https://issues.apache.org/jira/browse/COUCHDB-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13843678#comment-13843678
]
Nathan Vander Wilt commented on COUCHDB-1950:
---------------------------------------------
So the book (http://guide.couchdb.org/draft/conflicts.html) and the wiki
(http://wiki.apache.org/couchdb/Replication_and_conflicts) both tell me as a
user to do ± the following:
1. `GET somedoc?conflicts=true`
2. if there are conflicts, figure out what document state one the *app* wants
to win, making it so by (optionally) writing a new revision of one of the leafs
and then `DELETE somedoc?rev=unwanted` all the others
This glosses over the resolution strategy and any error handling for the
writes, but I think is a fair summary of what I was told to do as an app
developer?
Basically my job as an app developer is to (correctly…NOT glossing over error
handling!) write the boilerplate that turns:
{code}
,--> r2a -> r3a
r1 --> r2b -> r3b
`--> r2c -> r3c
{code}
into:
{code}
,--> r2a -> r3a
r1 --> r2b -> r3b -> (r4b deleted)
`--> r2c -> r3c -> (r4c deleted)
{code}
…or:
{code}
,--> r2a -> r3a -> r4a
r1 --> r2b -> r3b -> (r4b deleted)
`--> r2c -> r3c -> (r4c deleted)
{code}
Again, this is correct, right?
If this is how I should be handling conflicts, then — and AFAICT this is the
same point others have been trying to make — what is so problematic about
having People Who Understand CouchDB enapsulate the proper "detect+resolve
conflicts" meta-logic in such a way that all People Like Me have to write is
the app-specific logic as a JavaScript callback?
Isn't this what we already have for map/reduce, for validate_doc_update, for
update handlers…? Putting the logic closer to the data, abstracting it in such
a way as to corral implementations towards correctness, paving the cowpaths so
as to reduce boilerplate — how would doing the same for conflict resolution be
problematic?
> 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)
