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
34417	AlterField migration on ForeignKey field re-creates foreign key constraints unnecessarily	Ömer Faruk Abacı	Bhuvnesh	"Let's assume that we have the following models:

{{{
class Bar(models.Model):
    pass

class Foo(models.Model):
    bar = models.ForeignKey(Bar, related_name=""foos"", on_delete=models.CASCADE)
}}}

The migration that creates these models will add an index to the `bar` field of `Foo` model, this is well-documented and there is no problem up until now. But when we do the following change to drop the index on the ForeignKey field:


{{{
class Foo(models.Model):
    bar = models.ForeignKey(..., db_index=False)
}}}

Then we have a migration that results in the following SQL statement:


{{{
BEGIN;
--
-- Alter field bar on foo
--
SET CONSTRAINTS ""foos_foo_bar_id_efb062ad_fk_foos_bar_id"" IMMEDIATE;
ALTER TABLE ""foos_foo""
    DROP CONSTRAINT ""foos_foo_bar_id_efb062ad_fk_foos_bar_id"";

DROP INDEX IF EXISTS ""foos_foo_bar_id_efb062ad"";

ALTER TABLE ""foos_foo"" ADD CONSTRAINT ""foos_foo_bar_id_efb062ad_fk_foos_bar_id""
    FOREIGN KEY (""bar_id"")
    REFERENCES ""bars_bar"" (""id"")
    DEFERRABLE INITIALLY DEFERRED;
COMMIT;
}}}

I believe that we shouldn't be needing to re-create the FK constraint, so the following SQL should suffice:


{{{
BEGIN;
--
-- Alter field bar on foo
--
DROP INDEX IF EXISTS ""foos_foo_bar_id_efb062ad"";
COMMIT;
}}}

Actually the main problem here is that dropping & adding constraints locks the entire table, and it might be catastrophic for some live production databases. IMHO this should either be documented or refactored. I look forward to hear your opinions on this, thank you in advance!"	Cleanup/optimization	assigned	Migrations	4.1	Normal			Adam Johnson Dmytro Litvinov	Accepted	1	0	0	1	0	0