On Jun 28, 2007, at 7:45 PM, Ian Bicking wrote:
> > 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. I can understand this... at least we're sure we shouldn't implicitly *commit* the transaction > > 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. However, this would couple the security-exception-trapping middleware with the transaction manager. Right now, the mentioned middleware's responsability is very simple: Trap security exceptions and turn them into 403s or 401s (depending if there's a user logged in). it doesn't even handle authentication (which is handled above to provide a REMOTE_USER and/or wsgi_org.user_info and trapping 401s). I can also think of other layers which could change status codes, expecting all this layers to be aware that a transaction manager is in the stack and explicitly rollback any transaction doesn't favor loose-coupling from my POV. I believe that in this scenario the most straightforward way to signal that an error (or non OK) condition has ocurred is to through the HTTP status code hence the db transaction middleware should take it into account. The question of what status codes should be treated as errors is still open though... Alberto > > -- > 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 -~----------~----~----~----~------~----~------~--~---
