Opened 18 months ago
Last modified 18 months ago
#34568 closed Bug
makemigrations --update changes the name of custom migration name — at Version 2
Reported by: | David Sanders | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 4.2 |
Severity: | Release blocker | Keywords: | |
Cc: | Simon Charette, David Wobrock | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
This may be intentional behaviour but the docs don't mention this so creating a ticket to update docs or correct behaviour:
If you create a migration with a custom name:
$ ./manage.py makemigrations --name foo Migrations for 'update_rename': update_rename/migrations/0001_foo.py - Create model Foo
then running --update
will change the name "foo" to the autogenerated one based on the operations:
$ ./manage.py makemigrations --update Migrations for 'update_rename': update_rename/migrations/0001_initial.py - Create model Foo Deleted update_rename/migrations/0001_foo.py
My opinion is that it shouldn't as it violates the principle of least astonishment even though the --name
argument wasn't supplied.
EDIT:
This is my first time using --update and here are a few other observations which could indicate that it requires broader discussion:
- It doesn't utilise the --name argument so it's impossible to customise the name during --update
- It'd be nice to provide --no-optimize option to --update, here's my use-case: 3-step non-null field addition. After doing nullable step 1, elidable data migration step 2, I want to merge the step 3 non-null update into the migration but --update optimizes this into a single step.
Perhaps --update requires a rethink?
<moved to description>