Michael Bayer wrote: > in reality it might be needed for ConnectionProxy, or some other > object, to receive the "_handle_dbapi_exception()" event for this to > really work. This handling occurs at many places, including > statement execution, transaction commit/rollback, result row fetching, > and cursor creation.
There's a simple possible extension point in the DBAPIErrors re-casting logic (a straightforward chokepoint for exception analysis and change) but that has the disadvantage of being a global augmentation. > It's also suggesting that we might want to call ConnectionProxy a > ConnectionExtension (and PoolListener a PoolExtension ?) and just > start adding more "hooks" to it. The distinction I've been using for *Listeners vs *Extensions is that the Listeners are not given a significant opportunity to influence or reimplement the underlying toolkit operation. They just receive notices of events as they happen. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" 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/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
