I'm kind of surprised that there is no test case that would have identified the fact that delete_where() leaves the state corrupted. There would be no need to ask Fable if the problem gets identified by the test. And having a test will also catch all future problems that might arise in the same function. So maybe instead of asking Claude what is wrong it would be wiser to invest in test coverage.
The problem with the test was that it asserted that the records were deleted inside of the same transaction as the delete, so it missed the changed behavior where the delete didn't commit properly (it had committed properly prior to the new transactions work).
I also stopped reading the article there. This is major version 4 of a library about providing higher level db actions, i.e. transactions are paramount to make them atomic
Comments
I'm kind of surprised that there is no test case that would have identified the fact that delete_where() leaves the state corrupted. There would be no need to ask Fable if the problem gets identified by the test. And having a test will also catch all future problems that might arise in the same function. So maybe instead of asking Claude what is wrong it would be wiser to invest in test coverage.
The test coverage of sqlite-utils is solid - pytest-cov reports 95% total. The project has 9,973 lines of implementation code and 14,860 of test code.
Here's the delete_where() test: https://github.com/simonw/sqlite-utils/blob/7a52214624ae0e2c...
The problem with the test was that it asserted that the records were deleted inside of the same transaction as the delete, so it missed the changed behavior where the delete didn't commit properly (it had committed properly prior to the new transactions work).
I also stopped reading the article there. This is major version 4 of a library about providing higher level db actions, i.e. transactions are paramount to make them atomic