Opened 6 years ago

Closed 6 years ago

#29848 closed Bug (invalid)

If using db_column in a model makemigrations is wrong

Reported by: Erik Bent Owned by: nobody
Component: Database layer (models, ORM) Version: 2.1
Severity: Normal Keywords: migration
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


I have the following line in a model:

examplefield = models.CharField(db_column='ExampleField', max_length=75)

I changed the line into:

example_field = models.CharField(db_column='ExampleField', max_length=75)

If I run makemigrations the following is asked:
Did you rename boek.examplefield to boek.example_field (a CharField)? [y/N]

If I answer N there is an add column recorded in the migration file.
If I answer Y there is a rename from examplefield to example_field recorded in the migration file.

Both are wrong because there is an db_column in the CharField. The expected behavior is that the fIeld is not changed.

Change History (1)

comment:1 by Simon Charette, 6 years ago

Resolution: invalid
Status: newclosed

There is a difference between field and column renaming, it is expected that an AddField or RenameField is generated is this case depending on what's specified when prompted by the migration questioner during the makemigrations phase.

Django migration track all model state changes even the ones that don't result in DDL (e.g. RENAME COLUMN). What should be considered a bug is if running the migration containing the RenameField crashed or if it generated any SQL at all as that could be optimized (e.g. using migrate and sqlmigrate). From my local testing that doesn't seem to be the case though.

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