{"html_url": "https://github.com/simonw/sqlite-utils/issues/121#issuecomment-655673896", "issue_url": "https://api.github.com/repos/simonw/sqlite-utils/issues/121", "id": 655673896, "node_id": "MDEyOklzc3VlQ29tbWVudDY1NTY3Mzg5Ng==", "user": {"value": 9599, "label": "simonw"}, "created_at": "2020-07-08T18:08:11Z", "updated_at": "2020-07-08T18:08:11Z", "author_association": "OWNER", "body": "I'm with you on most of this. Completely agreed that the CLI should do everything in a transaction.\r\n\r\nThe one thing I'm not keen on is forcing calling code to explicitly start a transaction, for a couple of reasons:\r\n\r\n1. It will break all of the existing code out there\r\n2. It doesn't match to how I most commonly use this library - as an interactive tool in a Jupyter notebook, where I'm generally working against a brand new scratch database and any errors don't actually matter\r\n\r\nSo... how about this: IF you wrap your code in a `with db:` block then the `.insert()` and suchlike methods expect you to manage transactions yourself. But if you don't use the context manager they behave like they do at the moment (or maybe a bit more sensibly).\r\n\r\nThat way existing code works as it does today, lazy people like me can call `.insert()` without thinking about transactions, but people writing actual production code (as opposed to Jupyter hacks) have a sensible way to take control of the transactions themselves.", "reactions": "{\"total_count\": 1, \"+1\": 1, \"-1\": 0, \"laugh\": 0, \"hooray\": 0, \"confused\": 0, \"heart\": 0, \"rocket\": 0, \"eyes\": 0}", "issue": {"value": 652961907, "label": "Improved (and better documented) support for transactions"}, "performed_via_github_app": null}