This was causing an issue when calling the `migrate` command in a test case with
the `available_apps` attribute pointing to an application with migrations
disabled using the `MIGRATION_MODULES` setting.
Thanks to Tim Graham for the review.
Refs #24919
Backport of 4dcaa5871b70859952c6f9c437dfe1b5f10509f2 from master
Thanks to Geoffrey Sechter and the Django NYC group for the report and Markus
for the review.
Backport of c4e372aaf467ae41315cfe56a718a80469fc5318 from master
The test creates and deletes a model in the same migration, and the model
had an AutoField. On Oracle, AutoField's are set up using deferred SQL, which
in this case was trying to modify a table after it had dbeen removed.
Backport of c8b3fbe from master
Thanks to Trac alias mrgaolei for the report, Baptiste for the confirmation
and Tim for the review.
Backport of cc2ca9c550fbf8fca8684b373a3c8e3618eea08e from master
The change partly goes back to the old behavior for forwards migrations
which should reduce the amount of memory consumption (#24745). However,
by the way the current state computation is done (there is no
`state_backwards` on a migration class) this change cannot be applied to
backwards migrations. Hence rolling back migrations still requires the
precomputation and storage of the intermediate migration states.
This improvement also implies that Django does not handle mixed
migration plans anymore. Mixed plans consist of a list of migrations
where some are being applied and others are being unapplied.
Thanks Andrew Godwin, Josh Smeaton and Tim Graham for the review as well
as everybody involved on the ticket that kept me looking into the issue.
The new attribute is checked when the `migrate --fake-initial` option
is used. initial will be set to True for all initial migrations (this
is particularly useful when initial migrations are split) as well as
for squashed migrations.
If the only manager on the model is the default manager defined
by Django (`objects = models.Manager()`), this manager will not
be added to the model state. If it is custom, it needs to be
passed to the model state.
The idea behind this change is, that AlterUniqueTogether,
AlterIndexTogether and AlterOrderWithRespectTo can always be moved after
an Add/Alter/Rename/RemoveField operation if they don't refer to the
respective field and are not empty sets / None.
Combined with the optimizations of duplicate AlterUniqueTogether,
AlterIndexTogether, and AlterOrderWithRespectTo operations from
128caa1e16ec2627737748f75c8e55600a3df97f, these operations are optimized
in a later round of the optimizer.
Thanks Tim Graham for the review.
This is a regression caused by introducing rendered migration states in
1aa3e09c2043 and the _meta refactoring in fb48eb05816b.
Thanks to Danilo Bargen for reporting the issue and Marten Kenbeek and
Tim Graham for triaging the bug and providing the initial test case.
