--
Ticket URL: <https://code.djangoproject.com/ticket/24902>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/24902#comment:1>
Old description:
> 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.
New description:
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.
--
Comment (by carljm):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/24902#comment:2>
Comment (by MarkusH):
In that
--
Ticket URL: <https://code.djangoproject.com/ticket/24902#comment:3>
* status: new => closed
* resolution: => invalid
--
Ticket URL: <https://code.djangoproject.com/ticket/24902#comment:4>
Comment (by carljm):
That's fine, though I think we'll end up wanting to do this anyway if/when
#24900 is implemented.
--
Ticket URL: <https://code.djangoproject.com/ticket/24902#comment:5>