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