couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Parkin <>
Subject Re: Bulk Docs
Date Fri, 13 Mar 2009 09:38:37 GMT
Chris Anderson wrote:
> What I'm curious is why your application needs inter-document
> consistency. 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. Bulk doc consistency seems like an attempt to sweep under
> the rug the fact that you have interdependencies. I know it's a
> pragmatic difference, and that a bulk transaction isn't really a
> document (but it basically becomes a document if you want the
> transaction to stay together as it passes through replications).

Two responses.. Firstly I don't *need* atomicity and I know it's not
going to happen over replication. But I do desire consistency where
possible and I also desire a simple way to roll back a bunch of changes
if one fails..

I can't talk about the particular we're working on but I'd be interested
in what point you would generally recommending de-normalising to
(presumably before the point where you only have one document per
application!). At any point befere one doc per app you will almost
inevitably have dependencies, at least in most applications I've just
thought about I would have.

> Anyway, it may be worth rethinking multi-doc transactions as a
> combination of single doc updates and views. Eg: the bank example
> where you have a document per transaction, and an account is a view
> that sums up the values of all the transactions a given account is
> involved in...

As Anthony says, there is a balance between data normalisation and
performance regardless of type of storage used and the 'ideal'
theoretical schema isn't always the ideal actual one.

As a side note to Anthony. I'd be very interested in a fork or ongoing
patch that just applies the bulk docs apply/rollback model.


View raw message