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 14:22:07 GMT

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

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

So, an update is made, a resolver runs, removing some leafs. A running replication is triggered,
copying that resolution to other nodes. Oops, it introduces a conflict, a resolver runs, removing
some leafs. A running replication is triggered, copying that resolution to others nodes. Oops...

The problem with automatic removal of leafs contemporaneously with document updates is that
it eliminates the existing window where all leafs propagate to all replicas where, because
winner selection is deterministic, all replicas present the same leaf as the winner. This
problem is eliminated if we allow customisation of the read time winning algorithm.

We all agree that some pruning needs to happen, since performance drops as revision trees
widen (and that includes branches that end in deleted leafs, since we must keep those forever
too). It's almost impossible to imagine doing so in CouchDB, given its intended design (and
core value). To be done safely, we could only prune once every leaf at every replica has reached
every other replica, which obviously degrades our offline story. Users can resolve conflicts
at their app tier (or, much more typically, never do so) because they can determine when it's
safe to do. The difficulty in knowing when (or if) it is safe to prune a revision tree already
affects variants of CouchDB, like Cloudant, where multiple copies of a database are kept in
sync using replication. In theory, at least, we could truly purge losing branches once that
replication has completed for every pair of replicas. Doing so automatically for the general
case seems very problematic.

Even if we accept all this, do you think we have a chance of conveying the implications of
the ddoc-based conflict resolution feature to our users? Do you worry that the potential for
data loss that users can introduce this way will be attributed to their own actions and not
the database that let it happen?


> 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