couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: What happens with a document, if a conflict is not resolved?
Date Sun, 01 Nov 2009 21:29:33 GMT
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.

> 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.

Mime
View raw message