On Oct 31, 2008, at 3:54 PM, jason kirtland wrote:
> > 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. this is easy, we would just have the proxy class used by ConnectionExtension override _handle_dbapi_exception() the same way it overrides _cursor_execute() and _cursor_executemany(). > 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. so ConnectionExtension then since it can totally change what happens. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
