simonw
.delete_where() does not auto-commit (unlike .insert() or .upsert())
When you use the delete_where() function on a table, it never commits....
Is that intentional?
See #121 - I need to think harder about how this all interacts with transactions.
You can do this:
with db.conn:
db["mytable"].delete_where()
But that should be documented and maybe rethought.
I appreciate the response, it's just unexpected.
If I insert, it commits, if I update it commits, if I upsert it commits... if I delete.. it doesn't??? Confused me...
I did just db commit it... But it's confusing.
Independent of the transaction changes in #121 I may be able to check self.conn.in_transaction to see if a transaction is active and, if one is NOT active, execute the delete inside of one. https://docs.python.org/3/library/sqlite3.html#sqlite3.Connection.in_transaction
That's strange... this test here doesn't manually commit a transaction and passes:
https://github.com/simonw/sqlite-utils/blob/7805d53bcf11199bd1f2b07e05ae90151f9d0eb0/tests/test_delete.py#L17-L23
@spdkils can you share a minimal code example that exhibits the behavior you're seeing?
I confirm the bug. Happens for me in version 3.6. I use the call to delete all the records:
table.delete_where()
This does not delete anything.
I see that delete() method DOES use context manager with self.db.conn: which should help. You may want to align the code of both methods.
In a related issue, nearly a year later I just stumbled across this again, as I wondered why none of my rebuild-fts were rebuilding. It looks like: disable_fts in db.py commits; enable_fts partly commits except the last step (due to executescript committing a pending transaction); rebuild_fts won't commit unless manually done as above with e.g. a context manager.