Changes between Initial Version and Version 2 of Ticket #33197
- Timestamp:
- Oct 14, 2021, 7:09:52 PM (3 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #33197
- Property Triage Stage Unreviewed → Accepted
- Property Summary Providing prior implicit field name to db_column should be a noop → Renaming field and providing prior field name to db_column should be an SQL noop
-
Ticket #33197 – Description
initial v2 1 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. 1 Renaming a field and setting the prior implicit field name as the `db_column` to avoid db operations creates a migration emitting unnecessary SQL. Similar to #31826, which handled a very similar scenario but where there is no field rename, I would expect a SQL noop. I tested with SQLite and MySQL 5.7.31. 2 2 3 3 {{{ … … 32 32 }}} 33 33 34 Without renaming the field, follow the same flow and get an `AlterField` migration without SQL :34 Without renaming the field, follow the same flow and get an `AlterField` migration without SQL, which is what #31826 intended: 35 35 36 36 {{{