On Wed, Jan 28, 2009 at 1:19 PM, Damien Katz <[email protected]> wrote: > > -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. > That is good to hear, as I have been creating my own parallel structure to track md5 hashes for attachments.
-Jeff > -Damien > >> >> >> Regards, >> >> Brian. > >
