Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Mon, 9 Dec 2013 14:22:07 +0000 (UTC)
From: "Robert Newson (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12682276.1386030425314.2471.1386598927845@arcas>
In-Reply-To: <JIRA.12682276.1386030425314@arcas>
References: <JIRA.12682276.1386030425314@arcas>
Subject: [jira] [Commented] (COUCHDB-1950) ddoc-based conflict resolution
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/COUCHDB-1950?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D13=
843189#comment-13843189 ]=20

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

So, an update is made, a resolver runs, removing some leafs. A running repl=
ication is triggered, copying that resolution to other nodes. Oops, it intr=
oduces a conflict, a resolver runs, removing some leafs. A running replicat=
ion 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 propagat=
e to all replicas where, because winner selection is deterministic, all rep=
licas 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 d=
oing 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 ev=
ery other replica, which obviously degrades our offline story. Users can re=
solve conflicts at their app tier (or, much more typically, never do so) be=
cause they can determine when it's safe to do. The difficulty in knowing wh=
en (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 syn=
c using replication. In theory, at least, we could truly purge losing branc=
hes once that replication has completed for every pair of replicas. Doing s=
o 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 w=
ay 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=E2=80=A6
> It'd be great if a design document could include a conflict resolver func=
tion, in the vein of other "app logic" handler hooks like validate_doc_writ=
e. 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)" =E2=80=94 if it r=
eturns a document, that's the winner, if not the next design document in li=
ne gets a pass at it. (Bonus: if it throws, the conflict stays no matter wh=
at other resolvers say?)


--
This message was sent by Atlassian JIRA
(v6.1.4#6159)