Fixed #24184 -- Prevented automatic soft-apply of migrations

Previously Django only checked for the table name in CreateModel
operations in initial migrations and faked the migration automatically.
This led to various errors and unexpected behavior. The newly introduced
--fake-initial flag to the migrate command must be passed to get the
same behavior again. With this change Django will bail out in with a
"duplicate relation / table" error instead.

Thanks Carl Meyer and Tim Graham for the documentation update, report
and review.

1 files changed, 9 insertions, 1 deletions

diff --git a/tests/migrations/test_executor.py b/tests/migrations/test_executor.py
index e6482fb830..b88307ceea 100644
--- a/tests/migrations/test_executor.py
+++ b/tests/migrations/test_executor.py
@@ -2,6 +2,7 @@ from django.apps.registry import apps as global_apps
 from django.db import connection
 from django.db.migrations.executor import MigrationExecutor
 from django.db.migrations.graph import MigrationGraph
+from django.db.utils import DatabaseError
 from django.test import TestCase, modify_settings, override_settings
 
 from .test_base import MigrationTestBase
@@ -186,7 +187,14 @@ class ExecutorTests(MigrationTestBase):
                 (executor.loader.graph.nodes["migrations", "0001_initial"], False),
             ],
         )
-        executor.migrate([("migrations", "0001_initial")])
+        # Applying the migration should raise a database level error
+        # because we haven't given the --fake-initial option
+        with self.assertRaises(DatabaseError):
+            executor.migrate([("migrations", "0001_initial")])
+        # Reset the faked state
+        state = {"faked": None}
+        # Allow faking of initial CreateModel operations
+        executor.migrate([("migrations", "0001_initial")], fake_initial=True)
         self.assertEqual(state["faked"], True)
         # And migrate back to clean up the database
         executor.loader.build_graph()