Opened 3 years ago
Last modified 3 years ago
#33197 closed Cleanup/optimization
Providing prior implicit field name to db_column should be a noop — at Initial Version
Reported by: | Jacob Walls | Owned by: | nobody |
---|---|---|---|
Component: | Migrations | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Similar to #31826, I would expect no migration changes detected when a db_column
is added that matches the implicit field name. I tested with and without renaming the field on SQLite and MySQL 5.7.31. I'm not familiar enough with the review of #31826 to know whether these are distinct cases versus if it should be reopened.
class Apple(models.Model): core = models.BooleanField()
class Apple(models.Model): core_renamed = models.BooleanField(db_column='core')
Was apple.core renamed to apple.core_renamed (a BooleanField)? [y/N] y Migrations for 'renamez': renamez/migrations/0002_rename_core_apple_core_renamed_and_more.py - Rename field core on apple to core_renamed - Alter field core_renamed on apple
python manage.py sqlmigrate renamez 0002
showing unnecessary SQL:
BEGIN; -- -- Rename field core on apple to core_renamed -- ALTER TABLE "renamez_apple" RENAME COLUMN "core" TO "core_renamed"; -- -- Alter field core_renamed on apple -- ALTER TABLE "renamez_apple" RENAME COLUMN "core_renamed" TO "core"; COMMIT;
Without renaming the field, follow the same flow and get an AlterField
migration without SQL:
BEGIN; -- -- Alter field core on apple -- COMMIT;