couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Vander Wilt (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1950) ddoc-based conflict resolution
Date Mon, 09 Dec 2013 23:18:07 GMT

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

Mime
View raw message