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... :) 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 :) Alberto --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
