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 practical.
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.
Cheers, Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Plurality is not to be assumed without necessity -- William of Ockham (ca. 1285-1349)
