#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.
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)
follow-up: 2 comment:1 by , 6 years ago
Triage Stage: | Unreviewed → Accepted |
---|---|
Version: | 2.1 → master |
comment:2 by , 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 , 6 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:5 by , 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 , 6 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
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 , 16 months ago
Resolution: | wontfix → duplicate |
---|---|
Triage Stage: | Accepted → Unreviewed |
Duplicate of #34697.
Creating a Migration and assigning an unordered
depedencies
list and asserting they are sorted in the output should be an appropriate test.