If using db_column in a model makemigrations is wrong

[Erik Bent]

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.

[Simon Charette]

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.