#35635: Adding a field with a default in migrations following an index rename
seems
to fail
-------------------------------------+-------------------------------------
Reporter: Raphael Gaschignard | Owner: (none)
Type: Bug | Status: new
Component: Migrations | Version: 5.0
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Raphael Gaschignard:
Old description:
> 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/tree/ticket-700
> - Install Django
> - Run `sample_taggit/manage.py migrate`
New description:
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`
--
--
Ticket URL: <https://code.djangoproject.com/ticket/35635#comment:1>
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/01070190f1abcc04-57a21123-69c1-4f47-90fe-7b5651814c09-000000%40eu-central-1.amazonses.com.
