Re: [Django] #35635: Adding a field with a default in migrations following an index rename seems to fail

[Django]

#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 fol

Re: [Django] #35635: Adding a field with a default in migrations following an index rename seems to fail

[Django]

#35635: Adding a field with a default in migrations following an index rename 
seems
to fail
-+-
 Reporter:  Raphael Gaschignard  |Owner:  (none)
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  5.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Sanders):

 * resolution:   => needsinfo
 * status:  new => closed

Comment:

 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,
-- 
Ticket URL: 
Django 
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 django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070190f8ee6253-cd2519d8-dedf-45a9-85bb-8f3356480d07-00%40eu-central-1.amazonses.com.