I have no idea how tickets get tracked/worked on at this organization, so let me know if you want the stacktrace and I can add it
Marshall
added a comment - I have no idea how tickets get tracked/worked on at this organization, so let me know if you want the stacktrace and I can add it
.close()
"Close the cursor now (rather than whenever _del_ is called).
The cursor will be unusable from this point forward; an Error (or subclass) exception will be raised if any operation is attempted with the cursor."
When debugging your script, it turns out, that SQLAlchemy calls cursor.close() and afterwards wants to access cursor.rowcount while cursor was already closed.
I would say this is not a bug in Connector/Python, since it's clearly defined that the cursor become unusable after closing it. PyMySQL seems to ignore it:
>>> import pymysql
>>> conn=pymysql.connect(user="root")
>>> cursor=conn.cursor()
>>> cursor.execute("select 1 union select 2")
2
>>> cursor.close()
>>> cursor.rowcount
2
>>> cursor.execute("select 1 union select 2")
Traceback (most recent call last):
File"<stdin>", line 1, in <module>
File"C:\python\python-3.10\lib\site-packages\pymysql\cursors.py", line 148, in execute
whileself.nextset():
File"C:\python\python-3.10\lib\site-packages\pymysql\cursors.py", line 98, in nextset
returnself._nextset(False)
File"C:\python\python-3.10\lib\site-packages\pymysql\cursors.py", line 85, in _nextset
conn =self._get_db()
File"C:\python\python-3.10\lib\site-packages\pymysql\cursors.py", line 67, in _get_db
raise err.ProgrammingError("Cursor closed")
pymysql.err.ProgrammingError: Cursor closed
Georg Richter
added a comment - - edited According to PEP-249:
.close()
"Close the cursor now (rather than whenever _ del _ is called).
The cursor will be unusable from this point forward; an Error (or subclass) exception will be raised if any operation is attempted with the cursor."
When debugging your script, it turns out, that SQLAlchemy calls cursor.close() and afterwards wants to access cursor.rowcount while cursor was already closed.
I would say this is not a bug in Connector/Python, since it's clearly defined that the cursor become unusable after closing it. PyMySQL seems to ignore it:
>>> import pymysql
>>> conn = pymysql.connect(user = "root" )
>>> cursor = conn.cursor()
>>> cursor.execute( "select 1 union select 2" )
2
>>> cursor.close()
>>> cursor.rowcount
2
>>> cursor.execute( "select 1 union select 2" )
Traceback (most recent call last):
File "<stdin>" , line 1 , in <module>
File "C:\python\python-3.10\lib\site-packages\pymysql\cursors.py" , line 148 , in execute
while self .nextset():
File "C:\python\python-3.10\lib\site-packages\pymysql\cursors.py" , line 98 , in nextset
return self ._nextset( False )
File "C:\python\python-3.10\lib\site-packages\pymysql\cursors.py" , line 85 , in _nextset
conn = self ._get_db()
File "C:\python\python-3.10\lib\site-packages\pymysql\cursors.py" , line 67 , in _get_db
raise err.ProgrammingError( "Cursor closed" )
pymysql.err.ProgrammingError: Cursor closed
It's not really a fix but a workaround for pandas:
Instead of raising an exception when accessing rowcount property after cursor was closed, rowcount now returns -1.
This should also be in accordance to PEP-249:
"The attribute is -1 in case no .execute*() has been performed on the cursor or the rowcount of the last operation is cannot be determined by the interface."
Georg Richter
added a comment - It's not really a fix but a workaround for pandas:
Instead of raising an exception when accessing rowcount property after cursor was closed, rowcount now returns -1.
This should also be in accordance to PEP-249 :
"The attribute is -1 in case no .execute*() has been performed on the cursor or the rowcount of the last operation is cannot be determined by the interface."
George - I see the fix version is listed as 1.1.8 - has this been released yet? tried to upgrade via pip but that version isn't listed as available
Marshall
added a comment - George - I see the fix version is listed as 1.1.8 - has this been released yet? tried to upgrade via pip but that version isn't listed as available
Bug
Major
I have no idea how tickets get tracked/worked on at this organization, so let me know if you want the stacktrace and I can add it