incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hagen Overdick <six...@gmail.com>
Subject Re: Bulk updates and eventual consistency
Date Wed, 01 Apr 2009 12:23:10 GMT
>
> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message