couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <>
Subject Re: What happens with a document, if a conflict is not resolved?
Date Mon, 02 Nov 2009 10:20:41 GMT
On Sun, Nov 01, 2009 at 05:46:19PM -0500, Damien Katz wrote:
> I'm guessing you are taking some issue with the wording off this on the 
> website. "Most applications require no special planning to take  
> advantage of distributed updates and replication." from here: 

Yes, also this:
"Using just the basic replication model, many traditionally single server
database applications can be made distributed with almost no extra work"

This language is vague and unquantifiable. For example, I could easily argue
that "many" traditional database applications rely on SQL transaction
semantics, and such applications would require substantial rework to move to
couchdb with multi-master replication.

Don't get me wrong. I love CouchDB, and its incremental map-reduce is
without compare. Its replication model is logical and sound. But it does
take work to make use of it properly.

> For apps that are document oriented, I think this claim is true. I  
> suppose we could say "many" instead of "most" for less controversial  
> wording.
> However, for "many" apps there is no need for special planning, it's  
> enough to present the conflicting docs to the user

Right. So you're saying that the user interface should know about conflicts
and present them to the user, and I'd agree that's the minimum level of
conflict handling which is required of a multi-master application.

That requires writing your application so that it:
- fetches documents with GET ?conflicts=true
- iterates GET to fetch the others if _conflicts member is present
- displays them to the user
- allows the user to edit the final version
- saves the final version back and delete the conflicts

I consider writing your application this way "special planning" because new
users are discouraged from following this path.

- By default, couchdb hides conflicts in the HTTP API

- The experience they will get using PUT is that conflicts don't arise in
the first place, and this is also advertised as a feature:

| Document edits
| are made by client applications loading documents, applying changes, and
| saving them back to the database. If another client editing the same
| document saves their changes first, the client gets an edit conflict error
| on save. To resolve the update conflict, the latest document version can be
| opened, the edits reapplied and the update tried again.

Of course, what is written is completely true. What is unsaid is that this
feature is incompatible with multi-master replication.

I think all I'm asking for is:
- the overview documentation should be explicit that there are *two*
  mechanisms for dealing with conflicting updates
- make it clear that if you only implement the first/simple/obvious
  one, your application will not be multi-master capable



View raw message