couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: Transactional _bulk_docs
Date Wed, 04 Feb 2009 22:42:47 GMT
On 05/02/2009, at 6:26 AM, Chris Anderson wrote:

> What's at issue is the definition of transaction group operations. It
> is still possible to have transactional commits of data to disk.
> CouchDB 0.9 may not support checking that those updates are
> non-conflicting.

I need the behaviour that's been documented on the wiki and  
implemented until now. My app is 10 weeks away from walk-away  
deployment, and I don't have the time to design, implement, and test a  
putative ACID API on top of a bulk operation that doesn't provide ACID  
behaviour, particularly given that I don't think such an API is  

This change is a philosophical design decision, rather than being a  
technical issue. After all, it works that way now, and I've relied on  
on the described model. While I could deal with an API change, this  
goes way beyond that. IMO abandoning the concept of an ACID  
transaction is a step too far, and unnecessary.

Given the very wide nature of client distribution for this app,  
technology transfer requirements, and generic-platform status for the  
client etc, I think I have no alternative but to fork, which will  
probably require a different project name etc. C'est la vie.

Totally my fault for doing commercial deployment too soon :/

> I believe that supporting transactions of the current style, should
> possible as a layer on top of the new multi-node transaction support.

I suspect this isn't practical. Any intermediate states will be seen  
by competing concurrent operations. Dealing with race conditions and  
the propagation on the inconsistent state will be a nightmare, and  
probably practically impossible.


Antony Blakey
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Plurality is not to be assumed without necessity
   -- William of Ockham (ca. 1285-1349)

View raw message