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
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)
- 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?
Regards,
Brian.
