Opened 6 weeks ago
Closed 6 weeks ago
#35635 closed Bug (needsinfo)
Adding a field with a default in migrations following an index rename seems to fail
Reported by: | Raphael Gaschignard | Owned by: | |
---|---|---|---|
Component: | Migrations | Version: | 5.0 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
I have the following migration:
operations = [ migrations.RenameIndex( model_name="taggeditem", new_name="taggit_tagg_content_8fc721_idx", old_fields=("content_type", "object_id"), ), ]
I have created another migration after this one:
dependencies = [ ( "taggit", "0006_rename_taggeditem_content_type_object_id_taggit_tagg_content_8fc721_idx", ), ] operations = [ migrations.AddField( model_name="taggeditem", name="created_at", field=models.DateTimeField( blank=True, default=django.utils.timezone.now, null=True ), ), ]
This gives the following for sqlmigrate
:
BEGIN; -- -- Add field created_at to taggeditem -- CREATE TABLE "new__taggit_taggeditem" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "created_at" datetime NULL, "object_id" integer NOT NULL, "content_type_id" integer NOT NULL REFERENCES "django_content_type" ("id") DEFERRABLE INITIALLY DEFERRED, "tag_id" integer NOT NULL REFERENCES "taggit_tag" ("id") DEFERRABLE INITIALLY DEFERRED, CONSTRAINT "taggit_taggeditem_content_type_id_object_id_tag_id_4bb97a8e_uniq" UNIQUE ("content_type_id", "object_id", "tag_id")); INSERT INTO "new__taggit_taggeditem" ("id", "object_id", "content_type_id", "tag_id", "created_at") SELECT "id", "object_id", "content_type_id", "tag_id", '2024-07-27 00:31:47.134946' FROM "taggit_taggeditem"; DROP TABLE "taggit_taggeditem"; ALTER TABLE "new__taggit_taggeditem" RENAME TO "taggit_taggeditem"; CREATE INDEX "taggit_taggeditem_object_id_e2d7d1df" ON "taggit_taggeditem" ("object_id"); CREATE INDEX "taggit_taggeditem_content_type_id_9957a03c" ON "taggit_taggeditem" ("content_type_id"); CREATE INDEX "taggit_taggeditem_tag_id_f4f5b767" ON "taggit_taggeditem" ("tag_id"); CREATE INDEX "taggit_tagg_content_8fc721_idx" ON "taggit_taggeditem" ("content_type_id", "object_id"); CREATE INDEX "taggit_tagg_content_8fc721_idx" ON "taggit_taggeditem" ("content_type_id", "object_id"); COMMIT;
Note in particular the creating of two indexes with the same name.
Now, if I don't set a default in the AddField
operation , the sqlmigrate
result is simply as follows:
BEGIN; -- -- Add field created_at to taggeditem -- ALTER TABLE "taggit_taggeditem" ADD COLUMN "created_at" datetime NULL; COMMIT;
And if I comment out the RenameIndex
operation, I only create the index once, not twice, avoiding the issue.
Extra detail: I hit this because I have an index with a name, and then a RenameIndex
operation that renames it.
It seems like we would expect there to be a cleanup operation during a rename. Instead, it creates the migration twice.
I have only tested this out with the SQLite driver, and I have a suspicion it's only happening there, because... well... this seems like something that would break elsewhere.
Reproduced this with 5.1rc1 and 5.0.6
Reproduction:
- Checkout https://github.com/jazzband/django-taggit/commit/27640cebf6d7f03f5b34d0395bbf85422a6ef51f
- Install Django
- Run
sample_taggit/manage.py migrate
Change History (2)
comment:1 by , 6 weeks ago
Description: | modified (diff) |
---|
comment:2 by , 6 weeks ago
Resolution: | → needsinfo |
---|---|
Status: | new → closed |
Hi & thanks for the report.
Although I observed the exception on the branch you've linked, I couldn't reproduce this with a simple example following the steps provided.
My advice would be to reproduce this either with the simplest setup possible or through a unit test then paste the details here 👍
Closing with needsinfo for now until more info or someone with more time can investigate and confirm the presence of a bug with Django,