`apps` passed to post_migrate_signal should contain migrated appconfigs even when no migration has been applied to them

[tkhyn]

Hi,

I noticed that when one runs migrate without arguments (implicitly migrating all apps), the apps instance passed to emit_post_migrate_signal ​here) contains the migrated apps' configurations only in the first run.

On subsequent runs, the plan list (​here) is empty and post_migrate_apps is set to pre_migrate_apps (​here), i.e. the unmigrated apps.

For example, when calling migrate with the contenttypes app enabled, this means that after the first run update_contenttypes (​here) is passed an apps instance with contenttypes missing. The consequence is that update_contenttypes can not go further than ​this line.

To temporarily fix the issue and correctly trigger the post_migrate_signal so that the content types are properly updated each time migrate is called (and not only the first time), I need to run flush just after migrate. I don't think it should not be needed to run flush simply to correctly trigger the post_migrate_signal that will update the content types.

It worked fine in Django 1.9.9 as no project state apps instance is passed to emit_post_migrate_signal, and update_contenttypes uses the global apps instance.

I don't really know enough about the recent developments regarding apps management in Django, so I'm not sure what should be done to solve this issue. Thanks in advance if somebody has the time to look at it.

Context: I'm testing a reusable django app (​django-gm2m) which test suite includes migration tests for a number of mini test apps with different models (see ​here). Whenever I switch to another mini-app, the database needs not only to be flushed but also re-migrated and the contenttypes need to be updated ''

[Tim Graham]

I'm not sure I understand entirely. I think the idea is that if no migrations are applied, then content types shouldn't need to be updated. How can we reproduce the issue to look into it? Run the test suite for your app?

[tkhyn]

Thanks for the reply,

You could try and run the test suite for the app (I haven't pushed the changes to fix all the Django 2.0 warnings though so the suite will fail), or more simply use a minimal project in an environment with Django 1.10 installed:

hg clone https://bitbucket.org/tkhyn/dj10_syncdb
cd dj10_syncdb
hg update a7614832e38a7f8f21cf474dc328c295a9d8fc3c

In this state, the sample project has one unmigrated app app with one model MyModel. Lets migrate.

manage.py migrate

The django_content_type table now looks like:

id	app_label	model
1	admin	logentry
2	auth	permission
3	auth	user
4	auth	group
5	contenttypes	contenttype
6	sessions	session
7	app	mymodel

... and everything is ok so far. Let's add a new model to our unmigrated app.

hg update dfd8067076c1ceb7d9a1ae48ddc27c0dfd64044c
manage.py migrate

The django_content_type table has not changed. There should be a new line in django_content_type (app_label = app and model = mysecondmodel), and it's not there because update_contenttypes cannot proceed further than line 102 when migrate is called a second time.

A possible solution would be to transform app into a migrated app (I haven't checked it though), but given that it worked ok in django 1.9.9 I see this as a regression.

Feel free to let me know if you require additional info on this.

[tkhyn]

I should have added that using migrate --run-syncdb does not change the outcome (which can be expected when looking at the migrate management command implementation as it has no influence on the apps instance that is passed to the post_migrate signal)

[Simon Charette]

Hi tkhyn,

I can't look at this in details in the next few days but update_contenttypes should definitively be running for applications without migrations.

The fact applications with no migrations are present in apps on the first migrate run but not on subsequent ones look like a bug to me.

[tkhyn]

Thanks @charettes.

The fact applications with no migrations are present in apps on the first migrate run but not on subsequent ones look like a bug to me.

Note that on subsequent runs it's not app's config that is missing in the pre_migrate_apps' app configs, but actually contenttypes'config.

[Simon Charette]

Thanks for the follow up @tkhyn,

In this case I suspect the bug lies MigrationExecutor, it might be related to #26647.

[Simon Charette]

​PR

[Simon Charette <charette.s@…>]

In d1757d8d:

Fixed #27044 -- Included already applied migration changes in the post-migrate state when the execution plan is empty.

Refs #24100.

Thanks tkhyn for the report and Tim for the review.

[Simon Charette <charette.s@…>]

In 1c60765d:

[1.10.x] Fixed #27044 -- Included already applied migration changes in the post-migrate state when the execution plan is empty.

Refs #24100.

Thanks tkhyn for the report and Tim for the review.

Backport of d1757d8df486b689172d2584ded52fad916bcc33 from master