I suppose that it's worth mentioning that any support for nested transactions will not be portable to different databases (particularly MySQL) and probably would need to be documented accordingly.
Ian On Mon, May 17, 2010 at 7:50 PM, Piet Delport <pjdelp...@gmail.com> wrote: > 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. > > -- ======================================= 株式会社ビープラウド イアン・ルイス 〒150-0021 東京都渋谷区恵比寿西2-3-2 NSビル6階 email: ianmle...@beproud.jp TEL:03-6416-9836 FAX:03-6416-9837 http://www.beproud.jp/ ======================================= -- 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.
