On Jun 28, 2007, at 3:56 AM, Mike Orr wrote:
> > 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. I'd like to add here that I've got use-cases for the transaction boundary and session initialization being closer to the server than what the __before__ and __after__ hooks provide. For example, the authentication function I feed to AuthKit which uses a DB connection to retrieve the user and it's associated roles and permissions. I can think of other cases where other layers of middleware (more precisely, Middleware FrameWork Components) might want to access the database. Having all these layers plus the controller method (or other WSGI which sit below PylonsWSGIApp) wrapped in the same transaction sounds like a good idea to me. Alberto --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
