Opened 6 years ago

Closed 6 years ago

Last modified 16 months ago

#30029 closed Cleanup/optimization (duplicate)

Generate migration dependencies in a deterministic order

Reported by: Dakota Hawkins Owned by: Dakota Hawkins
Component: Core (Management commands) Version: dev
Severity: Normal Keywords: migrations, makemigrations
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

From 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.

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.

Change History (7)

comment:1 by Simon Charette, 6 years ago

Triage Stage: UnreviewedAccepted
Version: 2.1master

Creating a Migration and assigning an unordered depedencies list and asserting they are sorted in the output should be an appropriate test.

in reply to:  1 comment:2 by Dakota Hawkins, 6 years ago

Replying to Simon Charette:

Creating a Migration and assigning an unordered depedencies list and asserting they are sorted in 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.

comment:3 by Dakota Hawkins, 6 years ago

Owner: changed from nobody to Dakota Hawkins
Status: newassigned

comment:4 by Dakota Hawkins, 6 years ago

Has patch: set

comment:5 by Dakota Hawkins, 6 years ago

For what it's worth, I think a workaround may be to set 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.

comment:6 by Simon Charette, 6 years ago

Resolution: wontfix
Status: assignedclosed

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.

comment:7 by Mariusz Felisiak, 16 months ago

Resolution: wontfixduplicate
Triage Stage: AcceptedUnreviewed

Duplicate of #34697.

Note: See TracTickets for help on using tickets.
Back to Top