Opened 4 years ago
Last modified 4 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;