{{{
$ ls testproj/migrations/
0001_initial.py 0001_squashed_0002_thing_age.py 0002_thing_age.py
__init__.py
}}}
When it comes to disambiguating input, Django seems to believe that the
replaced migrations still need to be considered:
{{{
$ ./manage.py migrate testproj 0001
CommandError: More than one migration matches '0001' in app 'testproj'.
Please be more specific.
}}}
But if you actually try to disambiguate and specify one of the replaced
migrations, Django no longer thinks it exists (and isn't very graceful
about telling you so):
{{{
$ ./manage.py migrate testproj 0001_initial
Traceback (most recent call last):
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File
"/home/carljm/projects/django/django/django/django/core/management/__init__.py",
line 330, in execute_from_command_line
utility.execute()
File
"/home/carljm/projects/django/django/django/django/core/management/__init__.py",
line 322, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File
"/home/carljm/projects/django/django/django/django/core/management/base.py",
line 347, in run_from_argv
self.execute(*args, **cmd_options)
File
"/home/carljm/projects/django/django/django/django/core/management/base.py",
line 398, in execute
output = self.handle(*args, **options)
File
"/home/carljm/projects/django/django/django/django/core/management/commands/migrate.py",
line 135, in handle
plan = executor.migration_plan(targets)
File
"/home/carljm/projects/django/django/django/django/db/migrations/executor.py",
line 50, in migration_plan
self.loader.graph.node_map[target].children
KeyError: ('testproj', '0001_initial')
}}}
There could be several different approaches to fixing this, but my feeling
is that Django shouldn't prevent you from migrating to a replaced
migration. If a migration still exists on disk, even if it's been squashed
and you've fully migrated the squashed set, you should be able to migrate
back to a state within the squashed set. It seems like there might be
production rollback cases where that could be important, and I don't see
in principle why it shouldn't be possible.
If that turns out to be impractical, then I think Django oughtn't bother
you about resolving ambiguities with migration names it won't let you
migrate to anyway. And the "nonexistent" error for this case should be
nicer than a raw `KeyError`. (In Django 1.7 the error was "ValueError:
Node ('testproj17', '0001_initial') not a valid node", which is perhaps a
bit better, but not much.)
--
Ticket URL: <https://code.djangoproject.com/ticket/24900>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* stage: Unreviewed => Accepted
Comment:
I agree, that should be possible and I think it is possible.
--
Ticket URL: <https://code.djangoproject.com/ticket/24900#comment:1>
* cc: shaib (added)
Comment:
Just ran into this. FWIW, workaround, as long as we do '''not''' do what
comment:5:ticket:24902 recommends (which is to keep the state of squashed
migrations in the db), is to simply move the squashed migration file away,
migrate backwards to your heart's content, then bring it back.
--
Ticket URL: <https://code.djangoproject.com/ticket/24900#comment:2>
* owner: nobody => Jacob Walls
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/24900#comment:3>
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/14495 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/24900#comment:4>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/24900#comment:5>
* stage: Ready for checkin => Accepted
Comment:
I added two test methods, so bumping this back from RFC. Thanks for the
review, Shai!
--
Ticket URL: <https://code.djangoproject.com/ticket/24900#comment:6>
* version: 1.8 => dev
--
Ticket URL: <https://code.djangoproject.com/ticket/24900#comment:7>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/24900#comment:8>
* needs_better_patch: 0 => 1
* stage: Ready for checkin => Accepted
Comment:
I'd like to discuss alternatives before moving forward, see
[https://github.com/django/django/pull/14495#pullrequestreview-737044138
comment].
--
Ticket URL: <https://code.djangoproject.com/ticket/24900#comment:9>
* needs_better_patch: 1 => 0
Comment:
Updated implementation to reduce complexity.
--
Ticket URL: <https://code.djangoproject.com/ticket/24900#comment:10>
--
Ticket URL: <https://code.djangoproject.com/ticket/24900#comment:11>
* needs_better_patch: 0 => 1
* needs_tests: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/24900#comment:12>
* needs_better_patch: 1 => 0
* needs_tests: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/24900#comment:13>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/24900#comment:14>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"3219dd3388c437b4bd869b76ddd43c9cdad05090" 3219dd33]:
{{{
#!CommitTicketReference repository=""
revision="3219dd3388c437b4bd869b76ddd43c9cdad05090"
Fixed #24900 -- Allowed migrating backward to squashed migrations.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/24900#comment:16>
Comment (by Mariusz Felisiak <felisiak.mariusz@…>):
In [changeset:"9e17cc062c62eec1177aaf65ebebba43e074cde2" 9e17cc0]:
{{{
#!CommitTicketReference repository=""
revision="9e17cc062c62eec1177aaf65ebebba43e074cde2"
Refs #24900 -- Added MigrationLoader test for applying squashed
migrations.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/24900#comment:15>