Opened 6 years ago

Closed 21 months ago

#28785 closed New feature (wontfix)

Tracking migrations

Reported by: Ramez Kabbani Owned by: Abhinav Yadav
Component: Migrations Version: 1.11
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes 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 (10)

comment:1 by Tomer Chachamu, 6 years ago

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 by Sonu kumar, 6 years ago

Owner: changed from nobody to Sonu kumar
Status: newassigned

comment:3 by Tim Graham, 6 years ago

Has patch: set
Patch needs improvement: set

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

comment:4 by Manav Agarwal, 3 years ago

Owner: changed from Sonu kumar to Manav Agarwal

comment:5 by Manav Agarwal, 3 years ago

Patch needs improvement: unset
Last edited 3 years ago by Tim Graham (previous) (diff)

comment:6 by Mariusz Felisiak, 3 years ago

Needs tests: set
Patch needs improvement: set

comment:7 by Uzair Ali, 2 years ago

Owner: changed from Manav Agarwal to Uzair Ali

comment:8 by Abhinav Yadav, 23 months ago

Owner: changed from Uzair Ali to Abhinav Yadav

comment:9 by Adam Johnson, 21 months ago

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

comment:10 by Carlton Gibson, 21 months ago

Resolution: wontfix
Status: assignedclosed

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

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