> > IMO this is a questionable decision, but I'm in the minority.
Guess, after much thought about this, I am joining the minority. I base my argumentation on this excellent paper: http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf In essence, Pat Helland recommends to identify _entities_ which represent the maximum scope of _local_ serializability. Thanks to the bulk update mechanism, this used to be a whole couchdb, with the changes given, an entity maps to a single document now. The reason given here is sharding a single database, a concept which I would refuse, because it breaks the idea of a database as an entity in the first place. Btw, the reasoning that let to the removal of bulk_transactions can be applied to the single update as well, there is just no guarantee there won't be a conflicting update somewhere in the distributed environment. Also, I don't really see, how you want to provide all_or_nothing semantics assuming a sharded database. So, what's an entity for CouchDB? I very much prefer a whole db, because I can have partial updates (which is exactly what the old bulk_transaction provided). I don't want to use this for referencial integrity, but local serializability of updates. If you remove that, you will either force people to bad design (keeping everything in a single document and eventually ask for partial updates) or force them to replicate this functionality outside of CouchDB, leading to ugly clutches. Just my 2 Eurocents Hagen -- Dissertations are a successful walk through a minefield -- summarizing them is not. - Roy Fielding
