fetchone() triggers an exception after a sql.delete() on postgresql

[Former user]

This is using sqlalchemy-0.4.8

Consider this statement:

foo_table.delete(foo_table.c.id==1).execute().fetchone()

It will return None using sqlite as engine, while using postgresql it will trigger an exception:

  File "/home/turbogears/jails/knowledgeplaza/lib/python2.5/SQLAlchemy-0.4.8-py2.5.egg/sqlalchemy/engine/base.py", line 1653, in fetchone
    self.connection._handle_dbapi_exception(e, None, None, self.cursor)
  File "/home/turbogears/jails/knowledgeplaza/lib/python2.5/SQLAlchemy-0.4.8-py2.5.egg/sqlalchemy/engine/base.py", line 934, in _handle_dbapi_exception
    self.invalidate(e)
  File "/home/turbogears/jails/knowledgeplaza/lib/python2.5/SQLAlchemy-0.4.8-py2.5.egg/sqlalchemy/engine/base.py", line 641, in invalidate
    if self.__connection.is_valid:
AttributeError: 'Connection' object has no attribute '_Connection__connection'

The fix is to not fetchone() after the execute(), but imho it shouldn't trigger an exception under postgresql

[Mike Bayer]

SQLite returning None vs. PG raising an error on closed cursor access is an artifact of the behaviors of those DBAPIs and it would place undue burden on the ResultProxy to check for closed status on every fetchone() call. The incorrect detection of an "unexpected" close of a connection and the resulting attribute error is fixed in e98b9361294ab0cd2b336e55284310217c9b6e50 738e134f8c6a9ef6f79446d553bab4737e79cd89.