On 2017-05-31, Peter Otten <__pete...@web.de> wrote: > Jon Ribbens wrote: >> 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. > > ere's an excerpt of PEP 249: > > """ > .cursor() > Return a new Cursor Object using the connection. > > If the database does not provide a direct cursor concept, the module will > have to emulate cursors using other means to the extent needed by this > specification. [4] > > Cursor Objects > > These objects represent a database cursor, which is used to manage the > context of a fetch operation. Cursors created from the same connection are > not isolated, i.e., any changes done to the database by a cursor are > immediately visible by the other cursors. Cursors created from different > connections can or can not be isolated, depending on how the transaction > support is implemented (see also the connection's .rollback() and .commit() > methods). > """ > > I don't see how a cursor class that messes up interleaved fetchone() calls > can be compliant with the DB-API.
Why not? Either way, it appears that such classes are standard. -- https://mail.python.org/mailman/listinfo/python-list
