wemake-services / django-test-migrations

Test django schema and data migrations, including migrations' order and best practices.

Home Page:https://pypi.org/project/django-test-migrations/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Can't handle squashed migrations

ukch opened this issue · comments

My migration is doing something like the following:

Note: Parent and Child are both subclasses of Activity, and there is a generic relation between them (not sure if this is related to the issues I'm seeing)

@pytest.mark.django_db
def test_activity_migration(migrator: Migrator):
    old_state = migrator.apply_tested_migration(("app", an_old_migration_name))
    Parent = old_state.apps.get_model("app", "Parent")
    Child = old_state.apps.get_model("app", "Child")

    # Data setup
    parent = Parent.objects.create(...)
    Child.objects.create(..., parent=parent)
    orig_parents_values = list(Parent.objects.values())
    orig_children_values = list(Child.objects.values())

    # Finish all migrations on app
    state_0007 = migrator.apply_tested_migration(("app", the_newer_migration_name))
    state_0007_Parent = state_0007.apps.get_model("app", "Parent")
    state_0007_Child = state_0007.apps.get_model("app", "Child")
    state_0007_Activity = state_0007.apps.get_model("app", "Activity")
    assert models.Activity.objects.count() == 2

    # do not make assertion for the parent_activity_id
    orig_children_values[0].pop("parent_id")

    parent_0007 = state_0007_Parent.objects.values().first()
    child_0007 = state_0007_Child.objects.values().first()

    assert (
        state_0007_Activity.objects.filter(id=parent["activity_ptr_id"])
        .values(*orig_parents_values[0].keys())
        .first()
        == orig_parents_values[0]
    )
    assert (
        state_0007_Activity.objects.filter(id=childActivity["activity_ptr_id"])
        .values(*orig_children_values[0].keys())
        .first()
        == orig_children_values[0]
    )

After squashing 2 unrelated migrations together (using manage.py squashmigrations, this test no longer runs. It gives me this traceback:

______________________________________________________________ ERROR at teardown of test_activity_migration ______________________________________________________________
[snipped]

/home/joel/.cache/pypoetry/virtualenvs/relate-en3S9GuS-py3.8/lib/python3.8/site-packages/django_test_migrations/migrator.py:76: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/home/joel/.cache/pypoetry/virtualenvs/relate-en3S9GuS-py3.8/lib/python3.8/site-packages/django/core/management/__init__.py:181: in call_command
    return command.execute(*args, **defaults)
/home/joel/.cache/pypoetry/virtualenvs/relate-en3S9GuS-py3.8/lib/python3.8/site-packages/django/core/management/base.py:398: in execute
    output = self.handle(*args, **options)
/home/joel/.cache/pypoetry/virtualenvs/relate-en3S9GuS-py3.8/lib/python3.8/site-packages/django/core/management/base.py:89: in wrapped
    res = handle_func(*args, **kwargs)
/home/joel/.cache/pypoetry/virtualenvs/relate-en3S9GuS-py3.8/lib/python3.8/site-packages/django/core/management/commands/migrate.py:95: in handle
    executor.loader.check_consistent_history(connection)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

[snipped]
E                   django.db.migrations.exceptions.InconsistentMigrationHistory: Migration app.0015_squashed_migration_name is applied before its dependency app.0014_previous_migration_name on database 'default'.

/home/joel/.cache/pypoetry/virtualenvs/relate-en3S9GuS-py3.8/lib/python3.8/site-packages/django/db/migrations/loader.py:306: InconsistentMigrationHistory
___________________________________________________________ ERROR at teardown of test_automatic_child_activity ___________________________________________________________

[snipped]

/home/joel/.cache/pypoetry/virtualenvs/relate-en3S9GuS-py3.8/lib/python3.8/site-packages/django_test_migrations/migrator.py:76: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/home/joel/.cache/pypoetry/virtualenvs/relate-en3S9GuS-py3.8/lib/python3.8/site-packages/django/core/management/__init__.py:181: in call_command
    return command.execute(*args, **defaults)
/home/joel/.cache/pypoetry/virtualenvs/relate-en3S9GuS-py3.8/lib/python3.8/site-packages/django/core/management/base.py:398: in execute
    output = self.handle(*args, **options)
/home/joel/.cache/pypoetry/virtualenvs/relate-en3S9GuS-py3.8/lib/python3.8/site-packages/django/core/management/base.py:89: in wrapped
    res = handle_func(*args, **kwargs)
/home/joel/.cache/pypoetry/virtualenvs/relate-en3S9GuS-py3.8/lib/python3.8/site-packages/django/core/management/commands/migrate.py:95: in handle
    executor.loader.check_consistent_history(connection)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <django.db.migrations.loader.MigrationLoader object at 0x7f808bbd0fd0>, connection = <django.db.backends.postgresql.base.DatabaseWrapper object at 0x7f8091eaaa30>

[snipped]
E                   django.db.migrations.exceptions.InconsistentMigrationHistory: Migration app.0015_squashed_migration_name is applied before its dependency app.0014_previous_migration_name on database 'default'.

/home/joel/.cache/pypoetry/virtualenvs/relate-en3S9GuS-py3.8/lib/python3.8/site-packages/django/db/migrations/loader.py:306: InconsistentMigrationHistory

After this there is a second failure on the same test, related to the migrations not having applied successfully.

hi 👋

thank you for finding time to report this issue!

I am running django-test-migrations on squashed migrations in multiple projects and it works fine. I have tried to reproduce the exception you have listed, but without luck - could you please try to provide some minimal but runnable example of this issue?