Opened 3 years ago
Closed 3 years ago
#33509 closed Cleanup/optimization (fixed)
Add SQL comment to describe deliberately no-op migration operations
Reported by: | Adam Johnson | Owned by: | Adam Johnson |
---|---|---|---|
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
Currently when a field migration is a no-op, the operation description is output in SQL, but nothing else. This can be confusing as to which operations are no-ops. It could be clearer if we output an extra SQL comment when there are deliberately no statements to execute for a given migration operation.
Take for example this output:
BEGIN; -- -- Alter field name on Author -- ALTER ...; -- -- Alter field title on Book -- COMMIT;
The Author.name
field has an operation applied, whilst Book.title
needs no changes to the database. This isn't exactly clear from the output - is the COMMIT
part of the Book.title
change?
It could be clearer as:
BEGIN; -- -- Alter field name on Author -- ALTER ...; -- -- Alter field name on Author -- -- (no-op) COMMIT;
(Or perhaps more verbose wording, like "no SQL to execute")
I think this can help especially when there are consecutive operations with no-op SQL:
BEGIN; -- -- Alter field name on Author -- -- (no-op) -- -- Alter field name on Author -- -- (no-op) COMMIT;
(Inspired by #33470, where the OP suggested dropping such migration operation header comments.)
Change History (9)
comment:1 by , 3 years ago
comment:2 by , 3 years ago
I made a PR: https://github.com/django/django/pull/15416 . Not so hard. If the ticket is accepted I can finish off tests and docs.
It could also be a chance to move the “MIGRATION NOW PERFORMS OPERATION THAT CANNOT BE WRITTEN AS SQL” comment after the operation header, for consistency. I think it makes more sense to have the operation header first, then a comment about its contents afterwards anyway. Otherwise the "cannot be written as sql..." might be implied to mean the next several named operations.
comment:3 by , 3 years ago
Has patch: | set |
---|---|
Needs tests: | set |
Owner: | changed from | to
Status: | new → assigned |
Triage Stage: | Unreviewed → Accepted |
Type: | New feature → Cleanup/optimization |
comment:5 by , 3 years ago
Patch needs improvement: | set |
---|
comment:6 by , 3 years ago
Patch needs improvement: | unset |
---|
comment:7 by , 3 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
Thanks for the ticket. Do you have an implementation idea? As far as I'm aware we have the same issue here as in #33470, i.e. comments and generated SQL are on different layers (migrations vs. schema editor).