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 erlendaasland
Recipients berker.peksag, erlendaasland, lemburg, malin, serhiy.storchaka
Date 2021-12-06.10:13:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> I think this change is no problem.

Thanks, and thank you for looking reviewing this change.

> There is only one situation that a problem may occur. Write code with SQLite
> (2014-11-18), and run it on 3.7.15 (2012-12-12) ~, but
> this situation may be difficult to happen, we can note this situation in
> doc.

How realistic is this scenario? If you compile with, for example 3.14.0 or newer, you'd link with sqlite3_trace_v2, not sqlite3_trace, so the loader would prevent you from running with anything pre 3.14. AFAIK, we've never had such problems.

> More securely, if run on SQLite, and encounter
> SQLITE_ABORT_ROLLBACK error code, a prompt can be given to explain the
> reason.

You already get both an error message, an (extended) error code. That should be sufficient.

> Also note that the current main branch is buggy. If don't adopt this change
> or revert this change later, don't forget to fix the bug of msg407185
> (`pysqlite_Statement.in_use` flag is not reset).

It is a change of behaviour of the internal machinery. Does the change lead to wrong results (duplicate rows, wrong rows returned, no rows returned)? Corrupted/garbage data? Non-deterministic behaviour? Does any of the API's provided by sqlite3 not behave according to the documentation anymore?

NB: I plan to get rid of the in_use flag long before the beta sets in.
Date User Action Args
2021-12-06 10:13:34erlendaaslandsetrecipients: + erlendaasland, lemburg, berker.peksag, serhiy.storchaka, malin
2021-12-06 10:13:34erlendaaslandsetmessageid: <>
2021-12-06 10:13:34erlendaaslandlinkissue44092 messages
2021-12-06 10:13:34erlendaaslandcreate