-Damien
On Jan 28, 2009, at 1:45 PM, Brian Candler wrote:
Still on the subject of replication:
- Does anyone have any practical examples of application-specific
conflict resolution algorithms suitable for couchdb?
ISTM that although sometimes you might be able to construct the
revision
tree for a document, if compaction has taken place then all you'll
get
are the conflicting leaves. I'd be interested to see examples where
these can be automatically resolved.
I can only think of very limited examples:
- "most recent timestamp always wins" (perhaps suitable for keeping
the
most recent reading from an instrument)
- "append-only arrays": a field where clients only append values to
an
array, but never delete or change elements, could take the union of
the two versions
There is no generalized conflict resolution algorithm possible for
distributed edits. But for certain types of uses, as you note, it can
be automated.
For things that can't be automated, you can track diffs in the app for
later inspection. For each new revision, diff the changes with the
previous and attach the diff, or put the diffs into into another json
field. I'd recommend keeping them inside an attachment for efficiency
reasons. Then when you have a conflict, the user will have a full edit
history of the conflicts documents. The user picks the winner and
optionally updates it and deletes the losing conflict.
This is rather important to deal with though. Even futon doesn't
display
conflicts, so if your application doesn't take care to sweep them
up, it
will appear to the user as if one version is thrown away (even
though it
isn't)
Futon probably should display indicators for documents with conflicts
in the all_docs view, but otherwise your app will need to be coded to
look for the conflict field(s) and display notices to the user.
- If there are two conflicting documents with attachments, then
apart from
checking the sizes I can't see any way to compare them other than
downloading those attachments one by one. Would there be value in
computing an SHA1 and making it available in the stub? Or an MD5,
which
could also be exposed in a Content-MD5: header when downloading?
It's already planned to having integrity hashes in documents and
attachments. It's not that hard, just hasn't been done yet.
-Damien
Regards,
Brian.
