Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Django: Migrations depend on removed 3rd-party module

In my django project, I have been using django-taggit to add tagging capabilities to a model.

The migration adding tags also lists the initial taggit migration as dependency:

dependencies = [
    ('taggit', '0001_initial'),
    # …
]

At a later point in time, I have removed taggit everywhere, including INSTALLED_APPS.

The problem is that django can’t resolve that migration belonging to taggit, and raises an error.

What is the preferred solution in this scenario?

I can think of a two-step strategy:

  1. keep taggit in INSTALLED_APPS until all servers running the project are up to date
  2. squash migrations afterwards, so that the field does not show up any more, and only then remove taggit from INSTALLED_APPS
like image 535
David Aurelio Avatar asked Jan 14 '15 12:01

David Aurelio


People also ask

How does Django migration work?

Migrations are Django's way of propagating changes you make to your models (adding a field, deleting a model, etc.) into your database schema. They're designed to be mostly automatic, but you'll need to know when to make migrations, when to run them, and the common problems you might run into.

What happens if I delete Django migrations?

Deleting migration files means losing your history. This historical info is recorded in the django_migrations table in your database. if you delete migration files, you will get dependency errors. So Don't try to lose your history by deleting your migration files.

How does Django know which migrations have been applied?

As a part of the answer to the question "how does Django know what migrations have been run?", they store records of applied migrations in the database!


1 Answers

That's just about right. Note that you don't have to wait for all servers to be up-to-date before creating your squashed migration(s). From the documentation:

These files are marked to say they replace the previously-squashed migrations, so they can coexist with the old migration files, and Django will intelligently switch between them depending where you are in the history.

For the final step, you can even delete the old migration files, so there truly will be no more mention of taggit anywhere in your source:

You must then transition the squashed migration to a normal initial migration, by:

  • Deleting all the migration files it replaces

  • Removing the replaces argument in the Migration class of the squashed migration (this is how Django tells that it is a squashed migration)

like image 138
Kevin Christopher Henry Avatar answered Sep 28 '22 16:09

Kevin Christopher Henry