Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#24902 closed Bug (invalid)

Unapply squashed migration when any of the individual migrations are unapplied

Reported by: Markus Holtermann Owned by: nobody
Component: Migrations Version: 1.8
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 (last modified by Carl Meyer)

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 it won't be marked as unapplied.

Change History (5)

comment:1 Changed 5 years ago by Tim Graham

Triage Stage: UnreviewedAccepted

comment:2 Changed 5 years ago by Carl Meyer

Description: modified (diff)
Summary: Unapply separate migrations when squashed migrations existUnapply squashed migration when any of the individual migrations are unapplied

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.

comment:3 Changed 5 years ago by Markus Holtermann

In that case I think the issue is simply invalid. Thanks for looking into it, though.

Last edited 5 years ago by Markus Holtermann (previous) (diff)

comment:4 Changed 5 years ago by Markus Holtermann

Resolution: invalid
Status: newclosed

comment:5 Changed 5 years ago by Carl Meyer

That's fine, though I think we'll end up wanting to do this anyway if/when #24900 is implemented.

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