#33953 closed Bug (fixed)
RenameModel breaking change in 4.1 with ManyToManyField
Reported by: | Timothy Thomas | Owned by: | Iuri de Silvio |
---|---|---|---|
Component: | Migrations | Version: | 4.1 |
Severity: | Release blocker | Keywords: | RenameModel |
Cc: | Iuri de Silvio | 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
Steps:
1) Create model with a ManyToManyField and a db_table in the Meta.
2) Rename model and keep db_table the same as before
The generated db schema generated from generating migrations would change the columns on the ManyToMany relationship table to match the model name. This matched the generated sql for interacting with this model as well.
It is possible the db_table not changing is not required.
Example:
class Publication(models.Model): title = models.CharField(max_length=30) class Article(models.Model): class Meta: db_table = "article" headline = models.CharField(max_length=100) publications = models.ManyToManyField(Publication)
Changed to:
class OtherArticle(models.Model): class Meta: db_table = "article" headline = models.CharField(max_length=100) publications = models.ManyToManyField(Publication)
with the corresponding migration:
operations = [ migrations.RenameModel( old_name="Article", new_name="OtherArticle", ), ]
Previous behavior (4.0.6):
The corresponding (functional) SQL gets generated:
'SELECT COUNT(*) AS "__count" FROM "publication" INNER JOIN "article_publications" ON ("article"."id" = "article_publications"."publication_id") WHERE "article_publications"."otherarticle_id" = %s'
Current behavior (4.1):
The same SQL gets generated but fails. The schema that is now generated from running the same set of migrations on a fresh db would require:
'SELECT COUNT(*) AS "__count" FROM "publication" INNER JOIN "article_publications" ON ("article"."id" = "article_publications"."publication_id") WHERE "article_publications"."article_id" = %s'
as the column now matches the old model name. However, running that SQL would fail against our existing DB as it has ended up in a state that does not match the behavior of the existing migrations in the current version.
Change History (10)
comment:1 Changed 13 months ago by
Severity: | Normal → Release blocker |
---|---|
Triage Stage: | Unreviewed → Accepted |
Type: | Uncategorized → Bug |
comment:2 Changed 13 months ago by
Cc: | Iuri de Silvio added |
---|
comment:3 Changed 13 months ago by
Owner: | changed from nobody to Iuri de Silvio |
---|---|
Status: | new → assigned |
I would expect the field name using the db_table
to generate their name instead of the model name, but I agree it should not change the existing behavior.
Looks like an easy fix, I'll write a test and try it today.
comment:4 Changed 13 months ago by
Has patch: | set |
---|
I wrote a broken test and fixed the implementation.
comment:5 Changed 13 months ago by
Patch needs improvement: | set |
---|
comment:6 Changed 13 months ago by
Patch needs improvement: | unset |
---|---|
Triage Stage: | Accepted → Ready for checkin |
This was changed in afeafd6036616bac8263d762c1610f22241c0187 for #33201, which made RenameModel a no-op where the
db_table
is specified and unchanged.Something looks amiss though.
With the models you provide, creating migrations for
Article
and then the renamedOtherArticle
, I see the following in the shell:Relevant DB schema: