On Sun, Feb 15, 2009 at 8:48 PM, Antony Blakey <[email protected]> wrote: > It would suffice to say "don't presume that just because you update A before > you update B your code will see A if it can see B". This is the essence of > not having Monotonic Writes. It's not about transactions at all. Isolated > write groups are something that would a) optimise replication; and b) be > useful to application developers (especially with a fail-on-commit option), > but they aren't transactions in the traditional sense.
So it seems as though, when a long history is replicated under your model (interleaving many different client updates) we would end up sending a lot more data over the wire under your proposed model. In order to ensure that the isolation group stays together, even should replication fail before completion, we'd have to send the latest doc-rev for every doc touched in each isolated doc group. In the current system we just send the latest non-conflicted rev or all the conflict revs is they exist. It makes for a lot less data on the wire. (Correct me if I'm wrong.) Your story about comments being replicated without their assocaited posts is a good example of the counter-intuitive things that can happen when replication fails before completion. Thanks for that. I think these questions are interesting, I really do. However, in my mind, what makes CouchDB relaxing, is that we're not trying to be ambitious on the transactional guarantees front. So far, we've tried to give only the guarantees we know we can afford to give, and concentrate on getting them right. I certainly don't want to squelch any innovation here (and please keep discussing the topic). I just think that CouchDB's bare-bones guarantees are more powerful than we're giving them credit for. Robert's point that much of this can be implemented on top of CouchDB is an interesting one. If it is indeed the case, then the question becomes whether clients or the database should be responsible for providing the transactional API. -- Chris Anderson http://jchris.mfdz.com
