FAQ

[CouchDB-dev] Bulk Docs

Dean Landolt
Mar 15, 2009 at 11:21 pm

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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions