Alberto Valverde wrote: > > On Jun 28, 2007, at 12:42 AM, Ian Bicking wrote: > >> Jonathan LaCour wrote: >>> Ian Bicking wrote: >>> >>>> Personally I'd like to see something a bit different: >>>> >>>> * Way for a library to get "the" transaction manager. >>>> * Interface for that transaction manager, maybe copied from Zope. >>>> * Single convention for how to specify a database connection >>>> (ideally >>>> string-based). >>>> * Probably a way to get "the" configuration, so you can lazily get >>>> a connection based on the configured connection. >>>> >>>> The frameworks would setup the transaction manager and >>>> configuration, >>>> and database frameworks would basically consume this information. >>> This would be pretty much ideal, and would satisfy my use cases very >>> well. It would also allow framework authors to build in support >>> for any >>> ORM / database layer in an agnostic way, sort of like the Buffet API >>> does for templating systems. >>> >>> Then, we could also create a simple WSGI middleware for Pylons that >>> gives it TurboGears-like automatic transaction start/commit/rollback >>> on a per request basis. Only, we could make it configurable so that >>> it didn't happen on read-only operations. All of this would be ORM / >>> database layer agnostic, which would be very nice indeed. >> The way I see this working is something like (vaguely): >> >> def transaction_middleware(app): >> def wrapper(environ, start_response): >> manager = TransactionManager() >> environ['transaction.manager'] = manager >> try: >> app_iter = app(environ, start_response) >> except: >> manager.rollback() >> raise >> else: >> manager.commit() > > I see you've mentioned "vaguely" and that paste.transaction > implements it properly... but I just had to say this. An almost exact > implementation of that pseudocode caused me a very embarrassing bug > in which transactions were committed after the authorization > middleware trapped security exceptions and turned them into 403s. > Luckily it was only an internal app and the bug was noticed in- > house... :)
paste.transaction itself is something I should have really removed, as it's so incomplete. But yes, it's the basic pattern, but without a clear concept of a TransactionManager. > Bottom line is that the transaction middleware should rollback any > transaction if the status code is >= 400 to handle case like this > (and that using existing, well tested code is usually better than > rolling your own no matter how fun it is :) Er... I'm not sure about this. I'm not sure >=400 is really a failure. Maybe it is; I just don't feel comfortable making that claim generally. If you have a security exception that is caught, you could also look for the manager and roll it back exactly then, instead of expecting the middleware to do it. The middleware is just the furthest-out boundary for transactions, it's not the only place where you can control the transactions. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
