Now intermediate states in the database_backwards are cached, similar to
the executor's migrate() (or _migrate_all_backwards()). This makes the
migration run much faster (O(n) instead of O(n^2) over number of
database_operations).
When Django reraises an exception, it sets the __cause__ attribute even
in Python 2, mimicking Python's 3 behavior for "raise Foo from Bar".
However, Python 3 also ensures that all exceptions have a __traceback__
attribute and thus the "traceback2" Python 2 module (backport of Python
3's "traceback" module) relies on the fact that whenever you have a
__cause__ attribute, the recorded exception also has a __traceback__
attribute.
This is breaking testtools which is using traceback2 (see
https://github.com/testing-cabal/testtools/issues/162).
This commit fixes this inconsistency by ensuring that Django sets
the __traceback__ attribute on any exception stored in a __cause__
attribute of a reraised exception.
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
128caa1e16, 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
1aa3e09c20 and the _meta refactoring in fb48eb0581.
Thanks to Danilo Bargen for reporting the issue and Marten Kenbeek and
Tim Graham for triaging the bug and providing the initial test case.
Amos Onn
Tim Graham
Simon Charette
Raphaël Hertzog
Ana Vojnovic
Andrei Fokau
Benjamin Wohlwend
Markus Holtermann
Dražen Odobašić
Alex Hill
Tyson Clugg
Jeremy Satterfield
Caio Ariede
Piper Merriam
Andrei Kulakov
Kai Richard Koenig
Andriy Sokolovskiy
Steadman
Carl Meyer
Yoong Kang Lim
Matt Westcott
Marten Kenbeek
Piotr Jakimiak
Claude Paroz
Luis Del Giudice