Hi Russel, thanks for the response! On May 15, 12:47 pm, Russell Keith-Magee <russ...@keith-magee.com> wrote: > > 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.
I suspected as much; the current implementation doesn't make much sense unless managed blocks were informally introduced at some point without being relied upon to be transactional. While this makes managed blocks are a bit of a white elephant at the moment (the only code that can use them safely is code that doesn't need to be transactional), it might also be a minor blessing in disguise, in that they are not used widely enough for the problem to have major impact (yet). > 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. Right. (I'd like to note, though, that limiting commit_on_success to only top-level view functions is not enough to completely avoid this bug: for example, any usage of TransactionMiddleware will interact badly with it, especially if any intervening middleware uses the database.) > 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. Right, backward compatibility was big concern for me while investigating solutions to this. I believe that the proposed fix (making transaction blocks transactional as advertised) can be implemented in such a way that backward compatibility is preserved for almost all users: user code would not need to know anything about this change except that their currently-declared transaction blocks will operate correctly as intended, and no longer silently be vulnerable to broken edge cases as described above. In other words, the proposal is not to significantly change the meaning of transaction blocks, but rather to make them operate fully (instead of partially) as advertised: all code that currently uses them more or less as expected should continue to work as before, only more safely and correctly. Of course, this will need thorough review and testing, in case there turns out to be real cases where user code has somehow come to depend on the broken edge cases, but i can't offhandedly think of a scenario where this would easily happen. > 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. Thank you for your advice; this sounds like a good plan! I have informal tests for the scenarios described in the writeup, and will begin readying a prototype implementation as time allows. -- 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.
