couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: Bulk Docs
Date Fri, 13 Mar 2009 00:33:30 GMT

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. A  
simplified example - if you have user documents and you need to  
transactionally move a token from one to the other, you can't solve  
this problem by putting both users in one document, because the  
operation is arbitrary, between any two users. Putting all the users  
in one document kills concurrency.

There might be ways to restructure the data model to get around any  
one problem (such as inversion of link directions or reifying the  
token in my example), but in practice I've found that multiple  
refactorings don't always co-operate, and the data model then affects  
the UI because sometimes relationships need to model a user's  
expectation, rather than what is convenient for the software.

I like your bank example - a useful answer to questions such as this  
might be a catalogue of model transformations and alternatives.

Without impugning it's awesomeness, CouchDB will not be the right tool  
for every job, and the cost of alignment with CouchDB semantics needs  
to be considered as part of a design - that isn't perculiar to CouchDB.

Antony Blakey
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

There are two ways of constructing a software design: One way is to  
make it so simple that there are obviously no deficiencies, and the  
other way is to make it so complicated that there are no obvious  
   -- C. A. R. Hoare

View raw message