Erlend E. Aasland <erlend.aasl...@innova.no> added the comment:
> 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 > 3.8.7.2+ (2014-11-18), and run it on 3.7.15 (2012-12-12) ~ 3.8.7.1-, 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 3.8.7.1-, 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue44092> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
