This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients arigo, benjamin.peterson, berker.peksag, ghaering, larry, lemburg
Date 2017-01-02.09:37:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1483349822.89.0.823345141346.issue29006@psf.upfronthosting.co.za>
In-reply-to
Content
As general comment, I think you'd have to check which operation modes SQLite supports for the case of a transaction commit/rollback in the light of open cursors.

ODBC defines the following cases and each data source can specify a different behavior (https://msdn.microsoft.com/en-us/library/ms711769%28v=vs.85%29.aspx):

 * All cursors are closed, and access plans for prepared statements on that connection are deleted.

 * All cursors are closed, and access plans for prepared statements on that connection remain intact.

 * All cursors remain open, and access plans for prepared statements on that connection remain intact.

The Python DB-API does not specify any particular behavior (since this depends on the database backend), so I guess pysqlite3 should implement whatever SQLite supports per default in such cases (or make this configurable).

BTW: It is quite common for databases to support the second mode of operation:

 * All cursors are closed, and access plans for prepared statements on that connection remain intact.

since this allows pooling cursors to cache often used access plans.
History
Date User Action Args
2017-01-02 09:37:02lemburgsetrecipients: + lemburg, arigo, ghaering, larry, benjamin.peterson, berker.peksag
2017-01-02 09:37:02lemburgsetmessageid: <1483349822.89.0.823345141346.issue29006@psf.upfronthosting.co.za>
2017-01-02 09:37:02lemburglinkissue29006 messages
2017-01-02 09:37:02lemburgcreate