Opened 5 years ago

Closed 4 years ago

#26090 closed Bug (fixed)

Changing a ForeignKey to a OneToOne field leaves an extraneous index behind

Reported by: Aymeric Augustin Owned by: nobody
Component: Migrations Version: 1.9
Severity: Normal Keywords:
Cc: jon.dufresne@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

(This happened to me on PostgreSQL, I don't know about other databases.)

Assume a Child model that has a foreign key to its a Parent. makemigrations + migrate generate the following index:

CREATE INDEX app_child_<hash> ON app_child USING btree (parent_id);

If the foreign key is later turned into a one-to-one relationship, makemigrations + migrate generates the following constraint:

ALTER TABLE ONLY app_child
    ADD CONSTRAINT app_child_parent_id_key UNIQUE (parent_id);

The original index remains.

However, if the parent relationship had been originally declared as a one-to-one, only the constraint would have been generated, not the index. (I noticed after recreating all migrations from scratch for performance reasons and comparing the database schema.)

I believe that:

  • this falls within use cases where the migrations framework should keep the database state consistent
  • the index is redundant with the constraint and should have been dropped in that case

Change History (3)

comment:1 Changed 5 years ago by Tim Graham

Triage Stage: UnreviewedAccepted

See also the opposite case of OneToOneField to ForeignKey in #25317.

comment:2 Changed 4 years ago by Jon Dufresne

Cc: jon.dufresne@… added
Has patch: set

comment:3 Changed 4 years ago by Tim Graham <timograham@…>

Resolution: fixed
Status: newclosed

In 9356f63a:

Fixed #25317, #26090 -- Fixed swapping combinations of unique and db_index during migrations.

Note: See TracTickets for help on using tickets.
Back to Top