id,summary,reporter,owner,description,type,status,component,version,severity,resolution,keywords,cc,stage,has_patch,needs_docs,needs_tests,needs_better_patch,easy,ui_ux 26090,Changing a ForeignKey to a OneToOne field leaves an extraneous index behind,Aymeric Augustin,nobody,"(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_ 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",Bug,closed,Migrations,1.9,Normal,fixed,,jon.dufresne@…,Accepted,1,0,0,0,0,0