couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <>
Subject Re: Trouble with replication
Date Thu, 29 Jan 2009 10:29:53 GMT
On Wed, Jan 28, 2009 at 02:19:27PM -0500, Damien Katz wrote:
> 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 all makes perfect sense; however it does mean I have had to revise my
couchdb world view somewhat.

The tone at is optimistic:

"The CouchDB storage system treats edit conflicts as a common state, not an
exceptional one."

and even more so at

"Most applications require no special planning to take advantage of
distributed updates and replication"

This lead me to believe that handling replication conflicts at the
application layer would be straightforward - but on reflection, clearly it

What couchdb does for you is:
* it tells you that there's a conflict (if you remember to ask it)
* it picks one arbitrary version as the winner
* it remembers the loser version(s)

That's it.

The infrastructure doesn't by itself allow for git-style merging, since
couchdb doesn't retain all the document history. So as described above by
Damien, you will probably need to build a change history explicitly for each
document, and annotate it each time you make a change.

I'm not saying this is unreasonable. In fact it may be beneficial for
applications to keep an explicit audit trail on each document, and this may
include annotations which couchdb could not make by itself (such as the
user's application identity or source IP address, if couchdb is sitting
behind an application server)

However, this is a whole layer which couchdb application designers are going
to have to build, if they wish to use replication for anything other than
master->slaves. Furthermore they are going to have to design their data
structures appropriately; and all clients which make updates must update
them correctly, even clients which are not involved in resolving conflicts.
In my book, I'd call that "special planning".



View raw message