`makemigrations` ignores the index added to an existing model

In a project with Django 3.1.4, I am trying to add an index to an existing column in the database, so I modified the models.py file and added db_index=True to the field’s arguments.

However, calling the command python manage.py makemigrations app does not detect the additional indexing.

For testing, I made other changes to the model, e.g., adding a new field, and the command detected it correctly.

I am new to Django migrations and will appreciate any hints or suggestions. Also, please let me know if you need more information.

Technical Details:

  1. The source code before the change:
    entity_ct = models.ForeignKey(ContentType, related_name='value_entities',
  1. And after the change:
    entity_ct = models.ForeignKey(ContentType, related_name='value_entities',
                                  on_delete=models.DO_NOTHING, db_index=True)

I wouldn’t expect any changes to be made. A ForeignKey field automatically creates an index. If you’re using PostgreSQL, you can examine the schema and see that the indexes exist.

See the last paragraph in the section ForeignKey in the docs.

1 Like

Thank you, @KenWhitesell. My project is running MariaDB InnoDB, and the system behaviour is the same as you say.

It looks like there is no explicit instruction to create the index in the model definition, the migration, or its SQL translation. So, I think the database automatically creates an index for a foreign key by default.

I also found the below message on MySQL’s official website:

  • MySQL requires indexes on foreign keys and referenced keys so that foreign key checks can be fast and not require a table scan. In the referencing table, there must be an index where the foreign key columns are listed as the first columns in the same order. Such an index is created on the referencing table automatically if it does not exist. This index might be silently dropped later if you create another index that can be used to enforce the foreign key constraint. index_name , if given, is used as described previously.