[Django] #30029: Generate migration dependencies in a deterministic order
Django
-------------------------------------+-------------------------------------
Reporter: Dakota | Owner: nobody
Hawkins |
Type: | Status: new
Cleanup/optimization |
Component: Core | Version: 2.1
(Management commands) | Keywords: migrations,
Severity: Normal | makemigrations
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
From
[https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg
/django-users/GUBw8lp1U24/mMyIBeiSAgAJ this google groups discussion]:
> We haven't really deployed yet, so generally to make migrations we're
deleting existing migration files and re-running makemigrations.
>
> We have two apps, and one of them depends on the other as well as
django.contrib.auth. In that app's migrations the dependencies often swap
order seemingly indeterminately.
>
> [[Image(https://i.imgur.com/nJxyuXT.png)]]
>
> The resulting migration includes either:
>
> {{{
> class Migration(migrations.Migration):
> initial = True
> dependencies = [
> ('auth', '0009_alter_user_last_name_max_length'),
> ('app2', '0001_initial'),
> ]
> ...
> }}}
>
> or:
>
> {{{
> class Migration(migrations.Migration):
> initial = True
> dependencies = [
> ('app2', '0001_initial'),
> ('auth', '0009_alter_user_last_name_max_length'),
> ]
> ...
> }}}
>
> and it seems to switch back and forth with nearly every run.
>
> Does anybody know why, or how to nail down the order? It doesn't seem to
make a technical difference, but I'd like to avoid the churn/noise in our
repo.
According to Simon Charette in that discussion:
> It should be a simple matter of using sorted in
MigrationWriter.as_string[0].
I poked around the code a bit, in hopes of first writing a failing unit
test and then fixing the issue, but I'm not sure how to write the test
with multiple interdependent apps since `temporary_migration_module` seems
to support only a single app. Another concern is that the test may be
flaky since the current order is indeterminate... it may take some
arbitrary number of iterations to be reasonably certain the case could
have been reproduced by one of them.
I'd be happy to investigate further if somebody could help me get started
with some advice on writing that test.
--
Ticket URL: <https://code.djangoproject.com/ticket/30029>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: | Status: new
Cleanup/optimization |
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: migrations, | Triage Stage: Accepted
makemigrations |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* version: 2.1 => master
* stage: Unreviewed => Accepted
Comment:
[https://github.com/django/django/blob/3a4558b84f76c1dbe54c8c38e90e4048c2bd3e9a/tests/migrations/test_writer.py#L533-L544
Creating a Migration] and assigning an unordered `depedencies` list and
asserting they are sorted in
[https://github.com/django/django/blob/3a4558b84f76c1dbe54c8c38e90e4048c2bd3e9a/tests/migrations/test_writer.py#L545-L546
the output] should be an appropriate test.
--
Ticket URL: <https://code.djangoproject.com/ticket/30029#comment:1>
Django
-------------------------------------+-------------------------------------
Type: | Status: new
Cleanup/optimization |
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: migrations, | Triage Stage: Accepted
makemigrations |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Dakota Hawkins):
Replying to [comment:1 Simon Charette]:
>
[https://github.com/django/django/blob/3a4558b84f76c1dbe54c8c38e90e4048c2bd3e9a/tests/migrations/test_writer.py#L533-L544
Creating a Migration] and assigning an unordered `depedencies` list and
asserting they are sorted in
[https://github.com/django/django/blob/3a4558b84f76c1dbe54c8c38e90e4048c2bd3e9a/tests/migrations/test_writer.py#L545-L546
the output] should be an appropriate test.
Thanks! I was looking at the `test_makemigrations*` tests, that looks much
more promising. I'll work on it.
--
Ticket URL: <https://code.djangoproject.com/ticket/30029#comment:2>
Django
-------------------------------------+-------------------------------------
Type: | Hawkins
Cleanup/optimization | Status: assigned
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: migrations, | Triage Stage: Accepted
makemigrations |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: nobody => Dakota Hawkins
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/30029#comment:3>
Django
-------------------------------------+-------------------------------------
Type: | Hawkins
Cleanup/optimization | Status: assigned
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: migrations, | Triage Stage: Accepted
makemigrations |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/10741 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/30029#comment:4>
Django
-------------------------------------+-------------------------------------
Type: | Hawkins
Cleanup/optimization | Status: assigned
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: migrations, | Triage Stage: Accepted
makemigrations |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Dakota Hawkins):
For what it's worth, I think a workaround may be to set
[https://docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED
PYTHONHASHSEED] to some integer before making migrations. The migrations
wouldn't be sorted, but the order would stay the same (with the same
seed). Presumably the security implications of that would be minimal, as
you're just generating migration files.
--
Ticket URL: <https://code.djangoproject.com/ticket/30029#comment:5>
Django
-------------------------------------+-------------------------------------
Type: | Hawkins
Component: Core (Management | Version: master
commands) |
Keywords: migrations, | Triage Stage: Accepted
makemigrations |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: assigned => closed
* resolution: => wontfix
Comment:
After a bit more thought I agree with your conclusion Dakota, setting a
fixed `PYTHONHASHSEED` is probably the sanest way of dealing with that
given a lot more than just `Migration.dependecies` is likely to be ordered
differently for a different seed.
Closing as ''wontfix'' because this can be worked around in the rare cases
when ordering matters for your workflow. Feel free to file another ticket
to allow the exclusion of the header through the `makemigrations` command.
--
Ticket URL: <https://code.djangoproject.com/ticket/30029#comment:6>
Django
-------------------------------------+-------------------------------------
Type: | Hawkins
Cleanup/optimization | Status: closed
commands) |
Severity: Normal | Resolution: duplicate
Keywords: migrations, | Triage Stage:
makemigrations | Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* resolution: wontfix => duplicate
* stage: Accepted => Unreviewed
Comment:
Duplicate of #34697.
--
Ticket URL: <https://code.djangoproject.com/ticket/30029#comment:7>