cool, just noticed this and i'm really glad to see the discussion of transaction support, its the biggest thing stopping me from using django for production work.
regarding the patch, i'll address the transaction coupling in another respone in this thread, but the zope usage, i wanted to clarify. first the dependency is on parts of zope3 not zope2, and as jason alluded to in the initial thread, zope3 is designed from the ground up to be reusable as a set of python libraries, and is internally packaged that way ( using the zpkg tool, and eggs in the future ). as libraries they, unlike zope2, don't do any magic initialization or alter the runtime, meaning that they can play well with frameworks like django that do ;-) and their designed to be pythonic. the portions of zope3 that are needed for this patch can be trimmed down to 2 small packages. i'm not clear if the reason that zope3 is 'big reason not to include' is related to the above or perhaps nih, but imho zope3 has a lot of quality engineering work done on it, backed up by thousands of unit tests, and i think its good to benefit from the experience of others who have been solving complex problems with python for years. the patch itself is small, in part due to the functionality of the libraries z3 offers, and the nice design of django, but more importantly in addition to making django transactional it provides a solid foundation as well for future work with transactions in django, ie integration of multiple databases (simulatenous), distributed cache transactions, sending emails out (after transaction commit, or to disk for separate processing), etc. -kapil
