Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of b.candler@pobox.com
 designates 208.72.237.25 as permitted sender)
Date: Sun, 15 Mar 2009 20:55:18 +0000
From: Brian Candler <B.Candler@pobox.com>
To: Antony Blakey <antony.blakey@gmail.com>
Cc: dev@couchdb.apache.org
Subject: Re: Bulk Docs
Message-ID: <20090315205518.GA8755@uk.tiscali.com>
References: <6E088A0D-B5E4-4852-B1E0-6E49266F8622@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6E088A0D-B5E4-4852-B1E0-6E49266F8622@gmail.com>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)

On Fri, Mar 13, 2009 at 11:03:30AM +1030, Antony Blakey wrote:
>
> On 13/03/2009, at 10:45 AM, Chris Anderson wrote:
>
>> It seems like most of these problems just go away if you
>> put all the data that needs to be edited transactionally into a single
>> document.
>
> There is a tradeoff between document granularity and concurrency.

Indeed, and a subheading under "concurrency" is "ease of conflict
resolution".

I am tring to get around to writing up the "simple" and oft-quoted example
of a replicated set of bookmarks. I don't think it's as simple as is
claimed.

If you keep all your bookmarks in one document it's easy as pie to program
with, until you get a replication conflict, in which case couchdb gives you
no help whatsoever. It just tells you that here are two different sets of
bookmarks. People expect that a bookmark added on A will also be added on B,
and a bookmark deleted on A will also be deleted on B.

If you move to one-couchdb-object-per-bookmark then the replication becomes
much easier to deal with. But then you have to deal with the relationships
between documents - e.g. people expect their bookmarks to be ordered and
nestable.

Regards,

Brian.