couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Landolt <>
Subject Re: Bulk Docs
Date Sun, 15 Mar 2009 23:21:08 GMT
On Sun, Mar 15, 2009 at 4:55 PM, Brian Candler <> wrote:

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

I don't think Chris was suggesting you put *all *bookmarks in a single
document, just that the transactions themselves can be documents -- think
ledger entry in double-entry accounting. In some circumstances you can use a
reduce to roll these up into a useful view of your system state.

The bookmarks case you mention is interesting -- and definitely common. The
ordered list model is tough to accommodate, but you could always keep a doc
that maintains this order state. Ordering operations should always occur
distinctly from document change operations, so local consistency shouldn't
be a problem. But I concede that this'll be damn tough to replicate.

Another model -- the one I think Chris was hinting at -- would be to store
the relevant properties of every rearrangement operation individually, and
use a reduce (admittedly a very complex one) to get at the current ordering.
I'm sure that given enough swings at implementation, certain patterns will
emerge to make this kind of stuff a lot easier.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message