Python DB API - commit() v. execute("commit transaction")?
Jon Ribbens
jon+usenet at unequivocal.eu
Wed May 31 10:12:39 EDT 2017
On 2017-05-31, Peter Otten <__peter__ at 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.
More information about the Python-list
mailing list