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