This also makes migrations respect the base_manager_name and
default_manager_name model options.
Thanks Anthony King and Matthew Schinckel for the initial patches.
This deprecates use_for_related_fields.
Old API:
class CustomManager(models.Model):
use_for_related_fields = True
class Model(models.Model):
custom_manager = CustomManager()
New API:
class Model(models.Model):
custom_manager = CustomManager()
class Meta:
base_manager_name = 'custom_manager'
Refs #20932, #25897.
Thanks Carl Meyer for the guidance throughout this work.
Thanks Tim Graham for writing the docs.
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
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.
Akshesh
Loïc Bistuer
Sergey Fedoseev
Vytis Banaitis
Simon Charette
Alex Hill
Tim Graham
Raphael Gaschignard
Iacopo Spalletti
Jarek Glowacki
Markus Holtermann
Simon Charette
James Robert
Matthew Schinckel
Attila Tovt
Susan Tan
Berker Peksag
Claude Paroz
Noenglish Professorbut
Yoong Kang Lim
Scott Sexton
Pankrat
Amos Onn
Raphaël Hertzog
Ana Vojnovic
Andrei Fokau
Benjamin Wohlwend
Dražen Odobašić