From ff76fb7740a1f280831713274b90c07a70f8dc86 Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 4 Jul 2026 22:20:37 +0000 Subject: [PATCH] Clarify that db.atomic() is fine inside transactional migrations The manual-transaction warning could be read as covering db.atomic() too. Nested atomic() blocks are safe - they become savepoints inside the migration's transaction, preserving the all-or-nothing rollback guarantee. Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_01UnLnhsH25Nnv7LHhekUfPd --- docs/migrations.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/migrations.rst b/docs/migrations.rst index 61709c4..1bd1457 100644 --- a/docs/migrations.rst +++ b/docs/migrations.rst @@ -87,7 +87,7 @@ Some operations cannot run inside a transaction, for example ``VACUUM`` or chang A migration registered with ``transactional=False`` runs without a wrapping transaction, so if it fails part way through any changes it already made will not be rolled back, and re-applying will run the whole function again. -Avoid calling ``db.conn.commit()`` or otherwise managing transactions manually inside a transactional migration - register the migration with ``transactional=False`` if it needs to control its own transactions. +Avoid calling ``db.conn.commit()`` or otherwise managing transactions manually inside a transactional migration - register the migration with ``transactional=False`` if it needs to control its own transactions. Using ``with db.atomic():`` blocks inside a migration is fine: they nest as savepoints within the migration's transaction, so the migration as a whole still commits or rolls back as a single unit. See :ref:`python_api_transactions`. Applying migrations using the CLI =================================