Tracking migrations

[Ramez Kabbani]

Migrations exist in django in two locations:

1. In the codebase under app_name/migrations
2. As a db entry in django_migrations

I've come across the following scenario where I expected Django to give an error but it didn't not.

Assume we have 4 migrations for an app, and migration 1 through 3 are applied.

# Content of Postgres DB
     
    32 | app_name     | 0001_initial        
    33 | app_name    | 0002_migration2
    34 | app_name     | 0003_migration3

All migrations except 0001_initial.py were deleted including the folder pycache. We then run makemigrations

# Contents of migration folder after makemigrations was ran.
    
0001_initial.py  0002_name.py  __init__.py  __pycache__
    
# Run makemigrations
No Changes Detected
     
# Output of showmigrations
     
    app_name
    [X] 0001_initial
    [X] 0002_name

Contents of Postgres django_migrations, however, remain unchanged still with an entry for a third migration. I expected an error in one of the following commands but received none: makemigrations, migrate, showmigrations.

Also, migrate --fake app_name 0002_name does not lead to the deletion of 0003_migration3 entry in django_migrations

[Tomer Chachamu]

Agreed that a warning or system check for this situation would be nice. However, the docs currently suggest a way to turn a squashed migration into a normal migration, and it looks like any database that has had this done will then fail the system check. So, we would need:

• A way to turn squashed migrations into normal migrations in the future that does not cause the system check to fail,
• A solution for old databases to "reset" the system check, or we can just recommend people add it to SILENCED_SYSTEM_CHECKS (which would be a bit of a shame)

At the least, there might be a good place in the documentation to add a warning that migration files should not be removed.

[Tim Graham]

A ​PR adds a check to makemigrations. It still needs some improvement.

[Manav Agarwal]

​PR

[Adam Johnson]

#26760 added the --prune option to migrate, to clear up stale entries from django_migrations. Perhaps we no longer need to add a warning now there's this option.

[Carlton Gibson]

Agreed, good spot Adam.

Let's mark as wontfix given the --prune option, and the difficulty so far in providing an appropriate patch. (If future-someone wants to re-open with a PR for whatever is considered missing then that would be OK.)