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