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
27267	"Renaming a primary key fails with ""cannot drop constraint on table because other objects depend on it"""	Melvyn Sopacua	nobody	"When Django creates a foreign key constraint it uses a randomly generated string as part of the contraint name at the time it creates it. This has a side-effect that the names of these constraints are different for each database created. The better fix may then also be to get rid of this random string.

When one changes the type of a field that has foreign key references to it, then one cannot migrate the app. Attempts to use RunSQL fail, because as said, each database will have a different contraint name. This is most evident by just trying to create the test database with the following bit in a migration:

{{{#!python
    operations = [
        migrations.RunSQL(
            [
                'ALTER TABLE dpe_dpecharacter DROP CONSTRAINT {}'.format(
                    FKEY_NAME
                ),
           ],
    ]
}}}

So if the path is chosen not to get rid of the random string, we need a way to find out what the actual name of the foreign key constraint is, preferably wrapped as migrations.DropForeignKey().

The real world case that triggered this, was that initial design used a CharField as primary key, yet limitations in either or both contrib.contenttypes or Mezzanine prevented this from working correctly and an autogenerated primary key had to be used instead. Dropping the primary key is no issue, since it's name is predictable and consistent amonst different incarnations of the database."	Bug	closed	Migrations	1.8	Normal	needsinfo			Unreviewed	0	0	0	0	0	0