Make `post_migrate` dispatch the migration plan.

[Simon Charette]

Accepting based on +1's received from Aymeric and Claude in order to solve #24067, #24075.

[Simon Charette]

Created a ​PR for this ticket.

I'd like to give a try at fixing #24067 before getting this merged to make sure the provided plan is sufficient to issue ContentType renames.

[Markus Holtermann]

As already mentioned on the PR, I'm not sure the current API is stable enough (in terms of "Django doesn't crash", not in terms of "We change a function signature") for public usage. I'd like to have the alpha and beta for tests. Tim noted on IRC that changing the API after beta isn't really a thing we should do which I do understand.

A workaround we could also simply backport to 1.7 (and add plan and state in 1.9), is a check for the respective first migrations being applied:

In django.contrib.contenttypes.management:

def update_contenttypes(...):
    from django.db import connection
    from django.db.migrations.loader import MigrationLoader
    loader = MigrationLoader(connection)
    loader.load_disk()
    if not ('contenttypes', '0001_initial') in loader.applied_migrations:
        return

[Markus Holtermann]

PR: ​https://github.com/django/django/pull/4405

[Tim Graham]

See #25931 for a related issue with ContentType creation and backwards migrations.

[Amos Onn]

For issue #25931, it is sufficient to use the project_state after the migration, and no need to review the plan. This might make it an easier pick for testing that part of the interface.

As for the ContentType renames, I think that perhaps it would be cleaner to add signals for specific migration operations (such as RenameModel), which get passed the two states of the migration and perform their additional action (here, renaming the relevant ContentType entry), and have contrib.contenttypes connect to that - rather than having it sift through the whole plan itself. This way the change can also be done mid-migration, and enable the rest of the migration to rely on a consistent ContentType table.

[Simon Charette]

As for the ContentType renames, I think that perhaps it would be cleaner to add signals for specific migration operations (such as RenameModel), which get passed the two states of the migration and perform their additional action (here, renaming the relevant ContentType entry), and have contrib.contenttypes connect to that - rather than having it sift through the whole plan itself. This way the change can also be done mid-migration, and enable the rest of the migration to rely on a consistent ContentType table.

The down side of basing the detection on RenameModel only is the fact we don't handle any third party operation or usage of SeparateDatabaseAndState that could also alter the model state.

I agree with you that contrib.contenttypes shouldn't have to figure out which model were renamed from the plan by itself. Defining a utility function in the migrations module and using it the signal receiver would make more sense.

[Simon Charette]

​PR.

@amosonn, I ended up going with an approach similar to what you proposed.

[Tim Graham]

This may also fix #26588.

[Simon Charette]

​Updated PR