The cursor implementation is done completely in Python; the MySQL C API has no concept of cursors. In effect, they are a wrapper around MySQL Result objects (MYSQL_RESULT). Every time you execute a new query on a cursor, it discards the previous result.
The main issues for the server-side queries are:
1) You are required to read all rows before freeing the result; MySQLdb makes sure this happens for you.
2) You can not execute any queries on the connection until #1 happens.
The regular cursors actually do this internally:
1) Execute the query
2) Get the result
3) Fetch all rows into an internal Python list
4) Free the result
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's correct, but remember, each one contains the entire result set, which could be large, so be sure to close() them when you are done with them, or otherwise reuse them.
The order could matter in transactions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Should you use a new cursor for every query or should you reuse them? I suspect it matters more for server side cursors, but if you're not using them?
Thanks,
-Dan
The cursor implementation is done completely in Python; the MySQL C API has no concept of cursors. In effect, they are a wrapper around MySQL Result objects (MYSQL_RESULT). Every time you execute a new query on a cursor, it discards the previous result.
The main issues for the server-side queries are:
1) You are required to read all rows before freeing the result; MySQLdb makes sure this happens for you.
2) You can not execute any queries on the connection until #1 happens.
The regular cursors actually do this internally:
1) Execute the query
2) Get the result
3) Fetch all rows into an internal Python list
4) Free the result
So unless there's SS cursors involved, it shouldn't probably matter how many cursors you have or what order you do things with them in.
Thanks,
-Dan
That's correct, but remember, each one contains the entire result set, which could be large, so be sure to close() them when you are done with them, or otherwise reuse them.
The order could matter in transactions.