incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: What happens with a document, if a conflict is not resolved?
Date Sun, 01 Nov 2009 22:46:19 GMT

On Nov 1, 2009, at 4:29 PM, Brian Candler wrote:

> On Fri, Oct 30, 2009 at 06:46:24AM -0400, Damien Katz wrote:
>>> * Application writer curses couchdb, and curses the person who wrote
>>> "Most applications require no special planning to take advantage of
>>> distributed updates and replication".
>> It sounds like the dev didn't read the documentation.
> I believe the documentation is weak in this area, but I am  
> attempting to
> improve it.
> I think it's fair to say that the first documentation anyone reads  
> about
> CouchDB screams out: "RESTful HTTP API". Most people associate  
> "REST" with
> GET and PUT. This in turn leads them down the path of writing apps  
> which use
> PUT, and handling conflicts by trapping 409 responses and retrying  
> at write
> time.
> It works at first, but this approach will not serve them when they  
> get to
> distributed updates and replication. At very least, they'll need  
> another
> layer of conflict resolution, and that could involve substantial  
> application
> changes.
> With some "special planning" they could have decided to use the  
> somewhat
> obscure POST-to-_bulk_docs-with-all_or_nothing-true instead of PUT,  
> and
> implemented conflict resolution just once in a way which *does* also  
> work
> with distributed updates and replication.

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:

For apps that are document oriented, I think this claim is true. I  
suppose we could say "many" instead of "most" for less controversial  

However, for "many" apps there is no need for special planning, it's  
enough to present the conflicting docs to the user with simple diffing  
tools. This detection and handling is can be added after the app is  
built and is sufficient for many common use cases.

>> Patches are welcome, and most everything you propose could be done in
>> front end that's not that involved.
> Some of it can be done in a front-end.
> Reviewing my own code, most often I retrieve documents by using a  
> multi-key
> fetch against a view (either _all_docs or a user view). Writing a  
> front-end
> to that which also gives you the information needed to resolve  
> conflicts is
> hard - I think you'd end up having to GET each document  
> individually, which
> rather defeats the object of include_docs=true. I've raised that as
> COUCHDB-549.


> Regards,
> Brian.

View raw message