Claude d36639ed73 Run each migration inside a transaction ... Migrations.apply() now wraps each migration function and its _sqlite_migrations tracking row in db.atomic(), so they commit together: a failing migration rolls back cleanly, is not recorded, and stays pending, eliminating the double-apply hazard where a partially-failed migration left committed side effects behind. Migrations that cannot run inside a transaction (VACUUM, journal mode changes, manual transaction management) can opt out by registering with @migrations(transactional=False). Also fixed the test fixtures which used db.query() for INSERT statements - query() is a lazy generator, so those inserts never actually executed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UnLnhsH25Nnv7LHhekUfPd		2026-07-04 18:06:06 +00:00
..
__init__.py	New migrations system, ported from sqlite-migrate (#754)	2026-06-21 09:40:21 -07:00
__main__.py	Support 'python -m sqlite_utils', closes #368	2022-01-08 18:33:22 -08:00
cli.py	fix: Plugins are still loaded when running tests (#719)	2026-06-21 16:14:45 -07:00
db.py	Fix delete_where() leaving the connection in an open transaction	2026-07-04 17:57:35 +00:00
hookspecs.py	More type annotations (#697)	2025-12-16 22:11:47 -08:00
migrations.py	Run each migration inside a transaction	2026-07-04 18:06:06 +00:00
plugins.py	fix: Plugins are still loaded when running tests (#719)	2026-06-21 16:14:45 -07:00
py.typed	py.typed file so mypy picks up the types, closes #331	2021-11-14 15:21:04 -08:00
recipes.py	More type annotations (#697)	2025-12-16 22:11:47 -08:00
utils.py	Test against Python 3.15-dev, bump ty and Black (#738)	2026-05-17 16:52:48 -07:00