On 6/27/07, Mark Ramm <[EMAIL PROTECTED]> wrote: > > > 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.
The base controller's .__call__ method is your friend (but see below). Wrap the subclass call in a try-commit, You can also use the .__before__ and .__after__ methods unless you want to leave those empty for users. This avoids the need for fragile middleware and fussing with the WSGI environment. > 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. If you find that the base .__call__ is too late, you can ask Ben nicely for a hook method that wraps around the dispatched method call. > 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. Would a flag variable in a Routes rule work for this? One with a default value that means "this URL doesn't need a transaction". How is TG handling SQLAlchemy transactions now; i.e., which SQLAlchemy methods does it call? There's a transaction-centric pattern but I think it only works with SQL calls, not ORM use. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
