Discussed in #8023
I think we should try to hit this in terms of all the async dialects all of which have to do what we are doing here, which would be that we make a common mixin / base for all (edit: just asyncpg?) the async-adapted DBAPIs. for asyncpg it would be used here:
|
class Error(Exception): |
|
pass |
from ..exc import EmulatedDBAPIException
class Error(EmulatedDBAPIException):
passthat way people can look at EmulatedDBAPIException to see the fields, which would be like:
class EmulatedDBAPIException:
"""an exception class used to adapt non-DBAPI database driver exceptions
into DBAPI exceptions"""
message: str
"""string message indicating the error"""
orig: Exception
"""the original driver-level exception object"""that looks kind of boring so we can also add an accessor on
|
class DBAPIError(StatementError): |
called "driver_exception". This would work similarly to how we have "dbapi_connection" / "driver_connection" on Connection.
that way someone that knows asyncpg can receive the top level SQLAlchemy DBAPIException and just refer to .driver_exception to get all the asyncpg fields.
Discussed in #8023
I think we should try to hit this in terms of all the async dialects all of which have to do what we are doing here, which would be that we make a common mixin / base for
all(edit: just asyncpg?) the async-adapted DBAPIs. for asyncpg it would be used here:sqlalchemy/lib/sqlalchemy/dialects/postgresql/asyncpg.py
Lines 760 to 761 in 19f0566
that way people can look at
EmulatedDBAPIExceptionto see the fields, which would be like:that looks kind of boring so we can also add an accessor on
sqlalchemy/lib/sqlalchemy/exc.py
Line 525 in 19f0566
that way someone that knows asyncpg can receive the top level SQLAlchemy DBAPIException and just refer to .driver_exception to get all the asyncpg fields.