On Thu, May 13, 2010 at 11:01 PM, Piet Delport <pjdelp...@gmail.com> wrote: > Hi, > I'm working with a company that uses and maintains a commercial Django-based > commercial system, which requires reliable transactional integrity across > groups of database operations in a number of places (financial transfers, > and so on). > I've been investigating how Django's transaction management works, but found > to my surprise that Django's transaction managed blocks do not actually > ensure any transactional integrity, despite the documentation indicating > otherwise. (For example, "Use the commit_on_success decorator to use a > single transaction for all the work done in a function.") > I wrote up the following document, which describes the problem in a fair > amount of detail, as well as how Django's transaction management system may > be fixed to avoid it: > > Django Transaction Integrity > > I'd like to use this as a starting point for discussion; specifically, i > want to solicit feedback about the proposed solution approach (subsuming > nested transaction blocks): Does it sound reasonable to change > django.db.transaction's implementation to this? > I know this is not a small change, but i think it should be worth it if > transaction blocks are to be supported at all: there seems to be very little > point in keeping the current implementation where declaring a transaction > block doesn't actually make it transactional. > (This probably affects a number of current Django tickets, including at > least: #2227, #6669, #9964)
Hi Piet, You're certainly given us a lot to ruminate on here! I haven't had a chance to fully digest what you've written, but from my first inspection, you appear to have identified an area where Django has room for improvement. By way of a brief explanation of why things are they way they are: Firstly, Django's history in journalism-based websites breeds a history of high-volume reads, and low-volume, relatively simple writes. As a result, the transactional requirements have been fairly light. Secondly, although it's entirely legal Python to apply commit_on_success et al on arbitrary functions, the most common usage has been to apply them to view functions, not arbitrary processing functions. When these decorators are applied at the view level, you don't get the nesting problems you describe. The transaction functions as currently implemented are born of these two factors, combined with the "deadlines" part of "perfectionists with deadlines". In this context, Django's transactional integrity is fine - it's only in the complex cases where problems start to emerge. I'm certainly interested in addressing these complex cases, though. So what's the way forward? Procedurally - we're in the final throes of the release of 1.2, after which I will collapse for a little bit, then get on a plane to travel to DjangoCon.eu. In practical terms, this means that regardless of the merit of this discussion, not much is going to happen for about 2 weeks. I haven't completely absorbed the specific proposals from your document, but to put something into your mind for consideration: backwards compatibility is a very large consideration here. We can't arbitrarily change the way that transactions operate in existing code. Any change that we make must be by way of adding new functions/decorators, or by adding flags/modifiers to the existing functions and decorators with default values that reproduce existing behavior. So - thanks for your contribution. If you could kindly keep this warm for a couple of weeks, we can revisit this properly once Django 1.3 development is in full swing. In the interim -- anything you can do to turn this abstract set of proposals into some sample code, test cases, or prototype implementation is certainly most welcome, and the more concrete evidence you can present, the easier it will be to turn this into a change in trunk. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
