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: > http://couchdb.apache.org/docs/intro.html
Yes, also this: "Using just the basic replication model, many traditionally single server database applications can be made distributed with almost no extra work" http://couchdb.apache.org/docs/overview.html 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: http://couchdb.apache.org/docs/overview.html | 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 Regards, Brian.
