Changes between Initial Version and Version 2 of Ticket #24902


Ignore:
Timestamp:
Jun 3, 2015, 2:34:32 PM (9 years ago)
Author:
Carl Meyer
Comment:

Actually, look at the implementation of apply_migration and unapply_migration - when a squash migration is applied or unapplied, it marks only all the replaced migrations as applied or unapplied. So in the case described here, the individual replaced migrations _will_ be marked as unapplied, but the squash migration won't be.

In practice this doesn't really matter because the migration loader automatically sets the 'applied' state of any squash migration based on the applied state of all its replaced migrations. #24628 mattered only because you might remove all the replaced migrations and remove the 'replaces' kwarg from the squash migration, and then it isn't a squash migration anymore. You're only supposed to do that once everything is applied everywhere.

That said, I don't see any harm in correctly maintaining the applied state of the squash migration in the database in all cases; it does seem more robust and may avoid future problems.

Updated title and description for accuracy.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #24902

    • Property Triage Stage Unreviewed → Accepted
    • Property Summary Unapply separate migrations when squashed migrations exist → Unapply squashed migration when any of the individual migrations are unapplied

  • Ticket #24902 – Description

    initial v2  
    1 This is basically the inverse of #24628: separate migrations, that have been applied, and at a later stage the squash has been marked as applied. When you roll back before the squash the separate migrations won't be marked as unapplied.
     1This is basically the inverse of #24628: separate migrations, that have been applied, and at a later stage the squash has been marked as applied. When you roll back before the squash it won't be marked as unapplied.
Back to Top