Replies: 2 comments 8 replies
-
|
people dont necessarily use engine.connect() as a context handler, so putting this in there as an implicit behavior would be surprising and confusing. additionally, handling DBAPI exceptions has to be done immediately, because if people have things like handle_dbapi_exception() is a good method to use here but it does the "disconnect" check internally, so we would not want to do a separate disconnect check outside and then call it conditionally, applications that use DBAPI connections should explicitly opt in to this error handling. so i would propose a single context manager, perhaps like this: or maybe like this (I like this better): conn = engine.connect()
try:
with conn.use_dbapi_connection() as dbapi_connection:
cursor = dbapi_connection.cursor()
cursor.execute("select 1")
cursor.close()
finally:
conn.close()having folks opt in to the block explicitly with explicit behaviors is the way to go here. @CaselIT any thoughts? |
Beta Was this translation helpful? Give feedback.
-
In my case the separate check is needed to verify if the exception has already been handled ( |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Currently SQLAlchemy doesn't handle SQL dialect exceptions that are raised during execution of direct
dbapi_connectionordriver_connectionoperations.This may result in undetected disconnect errors and dead connections being returned to the connection pool.
However when using the
engine.connect()context handler, a SQL dialect exception that has not already been processed and wrapped by SQLAlchemy could easily be detected in its__exit__handler.I am currently using subclasses of
ConnectionandAsyncConnectionthat do the cleanup job well in my environment:Is there a chance that this could be accepted upstream?
Cheers,
--leo
Beta Was this translation helpful? Give feedback.
All reactions