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
-~----------~----~----~----~------~----~------~--~---
