Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-Id: <BA633C3E-AFE9-44FE-AF0C-F1FBC6D07AED@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <20090325084626.GB9031@uk.tiscali.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Where to add documentation for bulk updates
Date: Wed, 25 Mar 2009 10:15:02 +0100
References: <56a83cd00903240903i6c81d23dtefebf570e974fa48@mail.gmail.com>
 <20090325084626.GB9031@uk.tiscali.com>

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