It works just fine with every DB-API client I've used, including those
which only fetch results as needed. cx_Oracle, for instance. It's not
Python's fault if the underlying MySQL client interface is shitty.
On Wed, May 31, 2017 at 6:29 AM, Jon Ribbens <jon+use...@unequivocal.eu> wrote:
> On 2017-05-31, Peter Otten <__pete...@web.de> wrote:
>> Jon Ribbens wrote:
>>> You would do:
>>>
>>> cur.execute("SELECT ...")
>>> for row1 in cur.fetchall():
>>> cur.execute("SELECT ...")
>>> for row2 in cur.fetchall():
>>> ....
>>>
>>> and as far as the database is concerned, the query is over and done
>>> with as soon as you call fetchall(), so there is no possible overlap
>>> between the different queries.
>>
>> It's easy to simulate an iterable cursor with
>>
>> iter(cursor.fetchone, None)
>>
>> and then two cursors instead of one start making sense again.
>
> Indeed. I think this would not work, in general. For example, I think
> with MySQLdb it would work if you use a standard Cursor class, as that
> downloads the entire result set as soon as execute() is called, but it
> would not work with the SSCursor class which downloads results as
> needed. Again, this is because DB-API "cursors" are not SQL cursors.
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
