#33197: Renaming field and providing prior field name to db_column should be an
SQL
noop
--------------------------------------+------------------------------------
Reporter: Jacob Walls | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Old 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;
> }}}
New description:
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.
{{{
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, which is what #31826 intended:
{{{
BEGIN;
--
-- Alter field core on apple
--
COMMIT;
}}}
--
Comment (by Jacob Walls):
Thanks for having a look. I see now the scope of #31826 was just for flows
where the field is not renamed. So that makes this ticket a request to
extend this to field renames, which looks like was discussed as 3 and 4
[https://code.djangoproject.com/ticket/29245#comment:1 here].
> I assume the issue goes away if you swap the order of operations in your
migration?
If I switch the order to have `AlterField` followed by `RenameField`,
`FieldDoesNotExist` is raised when migrating. These are the operations:
{{{
operations = [
migrations.RenameField(
model_name='apple',
old_name='core',
new_name='core_renamed',
),
migrations.AlterField(
model_name='apple',
name='core_renamed',
field=models.BooleanField(db_column='core'),
),
]
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33197#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/073.e71ac5a87dc69b14fbb4e7cea5379da3%40djangoproject.com.
