I'm using MySQLdb-1.2.0 with MySQL 4.1 on Debian sarge.
I had a SELECT query that returned (unsigned long long)-1 when I called cursor.execute but there was no exception. I found out that the mysql API returns an error because one of the subqueries in the query returns more than one row. However, this error did not cause mysql_real_query to fail. Instead, mysql_store_result failed, and this caused the row count to come back as -1. This page from the mysql docs (http://dev.mysql.com/doc/refman/4.1/en/null-mysql-store-result.html) explains how such an error can come about.
I suspect that mysqldb should check for mysql_error after mysql_store_result as well as mysql_query. Indeed, in this case, a mysql_error check after mysql_(store|use)_result and calling _mysql_Exception correctly raises an exception instead of returning -1.
Has anybody seen this problem before? Is this a valid fix?
Ulas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And BTW, if you look at mysql.c (in _mysql_ResultObject_Initialize()), you'll see that it does check for an error result after calling mysql_store_result(); it returns a NULL in that case, which causes the caller (_mysql_ConnectionObject(store|use)_result()) to raise an exception. Checking mysql_error in the Python layer isn't going to help you.
It's not realistic to expect a evaluation of your fix without giving a code example that fails.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The patch to _mysql.c that worked for me is below. I'm not sure if we're talking about the same section of code but currently, the code does check for !result but it just returns 0 and does not raise an exception. I added code to set the exception and return -1.
Hi Folks.
I'm using MySQLdb-1.2.0 with MySQL 4.1 on Debian sarge.
I had a SELECT query that returned (unsigned long long)-1 when I called cursor.execute but there was no exception. I found out that the mysql API returns an error because one of the subqueries in the query returns more than one row. However, this error did not cause mysql_real_query to fail. Instead, mysql_store_result failed, and this caused the row count to come back as -1. This page from the mysql docs (http://dev.mysql.com/doc/refman/4.1/en/null-mysql-store-result.html) explains how such an error can come about.
I suspect that mysqldb should check for mysql_error after mysql_store_result as well as mysql_query. Indeed, in this case, a mysql_error check after mysql_(store|use)_result and calling _mysql_Exception correctly raises an exception instead of returning -1.
Has anybody seen this problem before? Is this a valid fix?
Ulas
And BTW, if you look at mysql.c (in _mysql_ResultObject_Initialize()), you'll see that it does check for an error result after calling mysql_store_result(); it returns a NULL in that case, which causes the caller (_mysql_ConnectionObject(store|use)_result()) to raise an exception. Checking mysql_error in the Python layer isn't going to help you.
It's not realistic to expect a evaluation of your fix without giving a code example that fails.
Hi Andy.
The patch to _mysql.c that worked for me is below. I'm not sure if we're talking about the same section of code but currently, the code does check for !result but it just returns 0 and does not raise an exception. I added code to set the exception and return -1.
Ulas
@@ -336,6 +336,10 @@
self->result = result;
Py_END_ALLOW_THREADS ;
if (!result) {
+ if (mysql_error(&(conn->connection))[0]) {
+ _mysql_Exception(conn);
+ return -1;
+ }
self->converter = PyTuple_New(0);
return 0;
}
Can you supply a code fragment and traceback? Exception would help too...
Note that MySQL-4.1 is not supported properly until MySQLdb-1.2.1.