Hi Brian,
first, thanks a lot for helping out with CouchDB, driving discussions
and
documentation, your work is highly appreciated.
On 25 Mar 2009, at 09:46, Brian Candler wrote:
This is where I think the introductory material on
couchdb.apache.org does
CouchDB a big disservice by overhyping: it implies strongly that
distributed, replicated applications are easy to write with CouchDB,
but I
don't think the reality matches that, at least not yet.
Of course, CouchDB is applied successfully to many projects. I have a
suspicion that most of them either (a) don't use replication at all,
or (b)
replicate mainly in a master->slave fashion, or (c) follow "append-
only"
pattern (new documents are added, but old documents are rarely
modified). In
these cases, the conflict issue is dodged entirely, which means
CouchDB's
built-in "support" for replication conflict handling is moot.
I'd like to comment on this since you've brought up this point in the
past.
CouchDB's conflict handling is not the final word on how conflicts have
to dealt with in an application. It is merely the building blocks with
clearly
defined and reliable behaviour that you can and have to build your
conflict
resolution on top of. Just like CouchDB doesn't magically handle
concurrent
writes, it simply rejects the second write and has the client deal
with it. Or
take replication: It is just an API with one POST endpoint and not a
mechanism
to keep two nodes in sync. Additional legwork, like using database
update
notifications, is needed.
Conflict resolution is very application dependent and, like "scaling"
and
sharding, cannot be done in a generic way. I think the misconception
here
is that you derive from the docs, that CouchDB's conflict resolution
does
solve things generically where it does not, it is just another
building block.
That said, I don't want to imply "dude, you're so wrong", I think we
need
to be more clear in the documentation about that, and thanks for
bringing
this up. Or maybe I'm wrong, wouldn't be the first time :)
Keep up the good work! :)
Cheers
Jan
--
