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
28065	Optimize SchemaEditor.alter_field() to avoid dropping foreign key constraints if not needed	Cameron Dawson	nobody	"If you just add a {{{related_name}}} to an existing foreign key, it will require a migration which then drops and re-creates the foreign key.  This is a non-DB, {{{meta}}} change only and shouldn't create a migration.  This is with MySQL.

With Models:

{{{
class Job(models.Model):
    id = models.BigAutoField(primary_key=True)
    name = models.CharField(max_length=30, null=True)
  
class JobDetail(models.Model):
    id = models.BigAutoField(primary_key=True)
    job = models.ForeignKey(Job)
}}}

my initial migration is:

{{{
operations = [
    migrations.CreateModel(
        name='Job',
        fields=[
            ('id', models.BigAutoField(primary_key=True, serialize=False)),
            ('name', models.CharField(max_length=30, null=True)),
        ],
    ),
    migrations.CreateModel(
        name='JobDetail',
        fields=[
            ('id', models.BigAutoField(primary_key=True, serialize=False)),
            ('job', models.ForeignKey(on_delete=django.db.models.deletion.CASCADE, to='polls.Job')),
        ],
    ),
]
}}}
Then if I modify the {{{JobDetail}}} model ForeignKey as follows:
{{{
job = models.ForeignKey(Job, related_name=""job_details"")
}}}
and run {{{makemigrations}}}, I end up with a migration:
{{{
operations = [
    migrations.AlterField(
        model_name='jobdetail',
        name='job',
        field=models.ForeignKey(on_delete=django.db.models.deletion.CASCADE, related_name='job_details', to='polls.Job'),
    ),
]
}}}
The {{{CREATE_INDEX}}} result in {{{sqlmigrate}}} for both migrations is identical:
{{{
CREATE INDEX ""polls_jobdetail_job_id_5561ba44"" ON ""polls_jobdetail"" (""job_id"");
}}}
We need to work around it with {{{migrations.RunSQL.noop}}} because the tables in our actual application are really large and dropping the index and re-creating is very expensive."	Cleanup/optimization	closed	Migrations	1.11	Normal	duplicate		emorley@…	Unreviewed	0	0	0	0	0	0