Alberto Valverde wrote: > 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.
Fair enough to all of the above, however all the feedback from Mike and Ian has made it clear to me that we need a few different things: 1. A standard transaction manager that can be plugged into any application, WSGI or not. It should be similar in scope and API to Zope's transaction manager, but free of Zope dependancies. 2. A piece of middleware that uses the transaction manager to rollback any active transactions in the case of an exception, or commit them in the other case. 3. Either some middleware or just a few lines inside the BaseController of the TurboGears template that starts a transaction on every request and puts it into the transaction manager. The first and second item are generally useful, and will allow you to manage transactions manually if you so desire. Any general-purpose middleware out there that needs to use a transaction can simply use the transaction manager, and all will be well. TurboGears will have the same behavior as it has had for a while, and since it happens in the __call__ of the BaseController, you can tweak it to your heart's content based upon the URI, HTTP method, or whatever you want. And, in my opinion, items #1 and #2 should be in Pylons by default, and the third item should be in the TurboGears template by default. There is, of course, some extra "stuff" we could add for nested transactions, and all of the cases he enumerated in his last email (required, requiresNew, supports, mandatory, etc), but I think the three things above will give a good set of building blocks for making those things easy to deal with. -- Jonathan LaCour http://cleverdevil.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---