Unapply squashed migration when any of the individual migrations are unapplied

[Markus Holtermann]

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.

[Carl Meyer]

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.

[Markus Holtermann]

In that

[Carl Meyer]

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