> It sounds like Pylons and TurboGears have very different paradigms > about how transactions are handled.
I can't do a side-by-side comparison, because I am not 100% clear on an example of the "right way" to handle transactions in Pylons. But I can describe what TurboGears 1.0 does. TG currently has an "automatic transaction per request" feature, which is very widely used. If a request fails for any reason, at any point the exception is propigated out, and causes a transaction rollback. We want to set up the transaction as early as possible. So that if you have validators which hit the DB (which many do) and you want that wrapped in a transaction that is done for you. And this is important because you can't do that in the controller method itself since validation happens in the decorator -- before you enter the controller method itself. And we want the transaction closed as late as possible so that if your internationalization fails or some other post controller action fails, you can rollback the transaction. Of course the problem with the current implementation of this feature is that all kinds of pages which don't actually change anything get transaction overhead that they don't need. So we are looking for the best way to control transactions on a per controller basis. --Mark Ramm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
