gh-93421: Fix sqlite3 cursor .rowcount for UPDATE ... RETURNING queries
#93520
Conversation
Does not work bca. executemany, but it solves the repro
|
🤖 New build scheduled with the buildbot fleet by @erlend-aasland for commit 5819902 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
|
🤖 New build scheduled with the buildbot fleet by @erlend-aasland for commit 5165a3a 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
|
🤖 New build scheduled with the buildbot fleet by @erlend-aasland for commit 1da6390 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
|
FYI, the failing buildbot are also failing on |
|
Haven't checked this method for problems. total_changes doc:
|
Please do; I appreciate your review.
Yes, I will make sure the 64-bit version is used, when available. Thanks for the heads-up! |
|
FTR, I will revert the DML check change in this PR; that is cleaner. |
|
Just found If change one row per second, it will overflow after 68 years: >>> (2**31-1)/3600/24/365
68.09625973490614Not afraid of you laughing, I hope a program can run 1000 years (or forever) without errors, in theory we can achieve this goal. |
Yes, both of the 64-bit changes APIs were added in 3.37.0.
Absolutely. But I also like to keep in mind that perfect is the enemy of good. IMO, a some of the sqlite3 issues have fallen to this; the proposed solution is not perfect, so we're stuck with API pains and bugs. A pragmatic view may, in some cases, be beneficial. For the record: for now, I think my alternative PR is the better solution for this issue. |
|
Closing in favour of gh-93526 |
Resolves #93421