makemigrations creates unnecessary migration for adding related_name to ForeignKey

[Cameron Dawson]

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.

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 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.