Opened 12 days ago

Last modified 11 days ago

#28785 assigned New feature

Tracking migrations

Reported by: Ramez Kabbani Owned by: Sonu kumar
Component: Migrations Version: 1.11
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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

Change History (2)

comment:1 Changed 12 days ago by Tomer Chachamu

Triage Stage: UnreviewedAccepted
Type: UncategorizedNew feature

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.

comment:2 Changed 11 days ago by Sonu kumar

Owner: changed from nobody to Sonu kumar
Status: newassigned
Note: See TracTickets for help on using tickets.
Back to Top