Changes between Initial Version and Version 1 of Ticket #27044


Ignore:
Timestamp:
Aug 10, 2016, 6:05:05 AM (8 years ago)
Author:
tkhyn
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #27044 – Description

    initial v1  
    55On subsequent runs, the `plan` list ([https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L136 here]) is empty and `post_migrate_apps` is set to `pre_migrate_apps` ([https://github.com/django/django/blob/1.10/django/core/management/commands/migrate.py#L197 here]), i.e. the unmigrated apps.
    66
    7 For example, when calling `migrate` with the `contenttypes` app enabled, this means that `update_contenttypes` ([https://github.com/django/django/blob/1.10/django/contrib/contenttypes/management.py#L89 here]) is passed an `apps` instance with `contenttypes` missing. The consequence is that `update_contenttypes` can not go further than [https://github.com/django/django/blob/1.10/django/contrib/contenttypes/management.py#L102 this line].
     7For example, when calling `migrate` with the `contenttypes` app enabled, this means that after the first run `update_contenttypes` ([https://github.com/django/django/blob/1.10/django/contrib/contenttypes/management.py#L89 here]) is passed an `apps` instance with `contenttypes` missing. The consequence is that `update_contenttypes` can not go further than [https://github.com/django/django/blob/1.10/django/contrib/contenttypes/management.py#L102 this line].
    88
    9 To temporarily fix the issue and correctly trigger the `post_migrate_signal` so that the content types are properly updated, 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.
     9To 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.
    1010
    1111It 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.
    … …  
    1313I 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.
    1414
    15 ''Context: I'm testing a reusable django app ([https://bitbucket.org/tkhyn/django-gm2m django-gm2m]) which test suite includes migration tests for a number of mini test apps with different models (see [https://bitbucket.org/tkhyn/django-gm2m/src/63af327624a45c5aed110546d3d705a6b1bf7c2b/tests/?at=release 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 !.''
     15''Context: I'm testing a reusable django app ([https://bitbucket.org/tkhyn/django-gm2m django-gm2m]) which test suite includes migration tests for a number of mini test apps with different models (see [https://bitbucket.org/tkhyn/django-gm2m/src/63af327624a45c5aed110546d3d705a6b1bf7c2b/tests/?at=release 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 !''
Back to Top