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.
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. On Oct 31, 2008, at 2:25 PM, Laurence Rowe wrote: > > Thinking about this a bit more carefully... I had thought that a > concurrency error could only occur at a transaction boundary, but I no > longer think this is the case - the "can't serialize" error would be > raised at the moment that the doomed update is performed. [*] > > This means that the connection proxy approach is required. However, I > do like the idea of annotating DBAPIErrors with normalized hints that > a concurrency error has occurred. It would isolate the db-dependent > code in the dialect and simplify my ConnectionProxy. > > [*] http://www.postgresql.org/files/developer/concurrency.pdf > > Laurence > > > On Oct 31, 5:04 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: >> Currently our DBAPI exception throws are "normalized" into the >> sqlalchemy.exc namespace, but are otherwise maintained to be >> identical >> to what the DBAPI threw. This is really important to us as the user >> can immediately identify exceptions which originate from the database >> or driver, and don't get bogged down in more SQLAlchemy-specific >> errors which have mysterious origins, imply that SQLA itself is >> malfunctioning or buggy, etc. It also would be an additional >> developmental burden to maintain correct exception-translation >> behavior across all dialects. >> >> That said, there are also occasional requests to further abstract >> away >> DBAPI errors of varying types into more abstract categories of >> exception. There are obvious advantages to this as well. Its an >> easy feature to balk at though since the exceptions thrown by DBAPIs >> vary wildly and the level of what you can realistically categorize >> without ambiguity is very low. >> >> The one area where we do have logic that inspects exceptions in a >> dialect specific manner and takes consistent action is the area of a >> dropped connection. We detect that and attempt to reconnect on next >> attempt, however we still propigate the original exception. The >> specific parsing for exceptions takes place within the dialects. >> >> So here my current thinking is that special abstractions of >> exceptions >> would not be a core behavior, but something you can enable, or add >> on. If a third party add-on were to provide this functionality, it >> would take the form of a ConnectionProxy which catches exceptions, >> inspects them, and re-propigates them. One way that the >> "inspection" logic could be kept within dialects without placing the >> burden on the 3rd party component might be for the SQLA dialects to >> attach "hints" to the current sqlalchemy.exc.DBAPIErrors which >> facilitate operations like this. that way we'd still send up the >> usual DBAPI-like exceptions but they'd have some more intelligence on >> them. >> >> any opinions ? >> >> On Oct 31, 2008, at 11:37 AM, Laurence Rowe wrote: >> >> >> >>> For zope.sqlalchemy I'd like to catch concurrent update errors at >>> commit time from the database (not the >>> sqlalchemy.orm.exc.ConcurrentModificationError) and propagate them >>> as >>> ConflictErrors to Zope's transaction manager so it may retry a >>> request. >> >>> ZPsycopgDA does this for PostgreSQL by looking in the error string >>> [*]: >> >>> except (psycopg2.ProgrammingError, >>> psycopg2.IntegrityError), e: >>> if e.args[0].find("concurrent update") > -1: >>> raise ConflictError >>> raise e >> >>> Would it be possible to abstract this in a database independent >>> manner >>> so that it could work for other databases too (at least those that >>> offer MVCC)? >> >>> [*]http://www.initd.org/svn/psycopg/psycopg2/trunk/ZPsycopgDA/db.py >> >>> Laurence > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
