This allows the removal of its O(n) .get_field_by_name method and many
other awkward access patterns.
While fields were initially stored in a list to preserve the initial
model definiton field ordering the auto-detector doesn't take field
ordering into account and no operations exists to reorder fields of a
model.
This makes the preservation of the field ordering completely superflous
because field reorganization after the creation of the model state
wouldn't be taken into account.
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.
When the primary key column is altered, foreign keys of referencing
models must be aware of a possible data type change as well and thus
need to be re-rendered.
Thanks Tim Graham for the report.
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.
Originally I added migrations to flake8 exclude because of long lines
in migration files, but there are other directories named migrations we
do want to check. We are not warning on line lengths yet anyway.
This reverts commit 66757fee7e.
Discussions have led to think that this functionality does not
bring significant benefits to justify the added complexity.
Read also discussions on ticket #22734.
