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 -~----------~----~----~----~------~----~------~--~---
