|
@@ -269,7 +269,7 @@ be removed (elided) when :ref:`squashing migrations <migration-squashing>`.
|
|
|
``RunPython``
|
|
|
-------------
|
|
|
|
|
|
-.. class:: RunPython(code, reverse_code=None, atomic=True, hints=None, elidable=False)
|
|
|
+.. class:: RunPython(code, reverse_code=None, atomic=None, hints=None, elidable=False)
|
|
|
|
|
|
Runs custom Python code in a historical context. ``code`` (and ``reverse_code``
|
|
|
if supplied) should be callable objects that accept two arguments; the first is
|
|
@@ -354,16 +354,19 @@ the ``schema_editor`` provided on these backends; in this case, pass
|
|
|
|
|
|
On databases that do support DDL transactions (SQLite and PostgreSQL),
|
|
|
``RunPython`` operations do not have any transactions automatically added
|
|
|
-besides the transactions created for each migration (the ``atomic`` parameter
|
|
|
-has no effect on these databases). Thus, on PostgreSQL, for example, you should
|
|
|
-avoid combining schema changes and ``RunPython`` operations in the same
|
|
|
-migration or you may hit errors like ``OperationalError: cannot ALTER TABLE
|
|
|
-"mytable" because it has pending trigger events``.
|
|
|
+besides the transactions created for each migration. Thus, on PostgreSQL, for
|
|
|
+example, you should avoid combining schema changes and ``RunPython`` operations
|
|
|
+in the same migration or you may hit errors like ``OperationalError: cannot
|
|
|
+ALTER TABLE "mytable" because it has pending trigger events``.
|
|
|
|
|
|
If you have a different database and aren't sure if it supports DDL
|
|
|
transactions, check the ``django.db.connection.features.can_rollback_ddl``
|
|
|
attribute.
|
|
|
|
|
|
+If the ``RunPython`` operation is part of a :ref:`non-atomic migration
|
|
|
+<non-atomic-migrations>`, the operation will only be executed in a transaction
|
|
|
+if ``atomic=True`` is passed to the ``RunPython`` operation.
|
|
|
+
|
|
|
.. warning::
|
|
|
|
|
|
``RunPython`` does not magically alter the connection of the models for you;
|
|
@@ -382,6 +385,11 @@ attribute.
|
|
|
|
|
|
The ``elidable`` argument was added.
|
|
|
|
|
|
+.. versionchanged:: 1.10
|
|
|
+
|
|
|
+ The ``atomic`` argument default was changed to ``None``, indicating that
|
|
|
+ the atomicity is controlled by the ``atomic`` attribute of the migration.
|
|
|
+
|
|
|
``SeparateDatabaseAndState``
|
|
|
----------------------------
|
|
|
|