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.
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.
The issue was hidden on 1.8+ until #24573 due to a bug inside the model
reloading process.
Forwardport of patch from ae87ad005f7b62f5fa5a29ef07443fa1bbb9baf0
Field.rel is now deprecated. Rel objects have now also remote_field
attribute. This means that self == self.remote_field.remote_field.
In addition, made the Rel objects a bit more like Field objects. Still,
marked ManyToManyFields as null=True.
The new signature enables better support for routing RunPython and
RunSQL operations, especially w.r.t. reusable and third-party apps.
This commit also takes advantage of the deprecation cycle for the old
signature to remove the backward incompatibility introduced in #22583;
RunPython and RunSQL won't call allow_migrate() when when the router
has the old signature.
Thanks Aymeric Augustin and Tim Graham for helping shape up the patch.
Refs 22583.
The migrations autodetector now issues AlterModelOptions operations for
Meta.managed changes instead of DeleteModel + CreateModel.
Thanks iambibhas for the report and Simon and Markus for review.
This reverts commit f36151ed169813f2873e13ca9de616cfa4095321.
Adding kwargs to deconstructed objects does not achieve useful
forward-compatibility in general, since additional arguments are silently
dropped rather than having their intended effect. In fact, it can make the
failure more difficult to diagnose. Thanks Shai Berger for discussion.
This removes the concept of equality between operations to guarantee
compatilibity with Python 3.
Python 3 requires equality to result in identical object hashes. It's
impossible to implement a unique hash that preserves equality as
operations such as field creation depend on being able to accept
arbitrary dicts that cannot be hashed reliably.
Thanks Klaas van Schelven for the original patch in
13d613f80011852404198dfafd1f09c0c0ea42e6.
