Opened 6 months ago

Last modified 5 months 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: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
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 (3)

comment:1 Changed 6 months 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 6 months ago by Sonu kumar

Owner: changed from nobody to Sonu kumar
Status: newassigned

comment:3 Changed 5 months ago by Tim Graham

Has patch: set
Patch needs improvement: set

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

Note: See TracTickets for help on using tickets.
Back to Top