[Answered ]-Migration file errors when trying to get rid of a third party Django app

by

1👍

✅

I’ve got a very similar situation in my project. I’ve tried squashing the migrations, but have run into issues with circular dependencies which I have yet to resolve…

Having said this, you might want to try squashing the migrations (see https://docs.djangoproject.com/en/4.2/topics/migrations/#squashing-migrations), as that would solve your issue – you would be able to delete the old migrations once your production deployments are updated to the point of these squashed migrations, and then you would be able to delete the app from your INSTALLED_APPS once all references to it are removed from your project and it’s migrations.

In short, you run ./manage.py squashmigrations with the app and migration number you want to squash up to, and Django will try to optimise the migrations by removing fields that were added and then removed in later migrations, among other things.

👤Raddish IoW

0👍

The older migrations are there for compatibility reasons, you need them if you have more than one version of the database state in different locations (i. e. development & production servers, developers personal computers etc.)

If you are sure that no one uses older versions which aren’t migrated yet, you do not need older migrations. So, just make sure everyone working on this project migrated on latest version of codebase, every server running this code migrated as well, and re-create migrations from scratch (delete all the migrations and make new ones).

Another workaround is to fake this table in older migrations: edit the very first migration introducing relations with third-party table in that way so it creates same model in your database and make sure every next migration uses this fake model instead of third-party model. Then edit the latest migration which deletes that relation so that would delete the fake model as well. This might also work.

👤Pavel Shishmarev

0👍

I recently had to migrate away from a third-party app in my Django project and encountered similar challenges with migration files and dependencies. Here’s how I successfully did it:

Step 1: Create a New Migration for Field Removal

You needed to remove a field (product) from my Executable model, which depended on Oscar’s ‘catalogue’ app. To do this, you should create a new migration specifically for this change:

python manage.py makemigrations your_app_name

In this new migration, you should remove the product field from the Executable model.

Step 2: Update Dependencies in Migration Files

In the new migration file (e.g., 0003_remove_executable_product.py), you have to update the dependencies. There was a line that looked like this:

dependencies = [
    ('sr_app', '0002_previous_migration'),
    ('catalogue', '0001_previous_migration'),  # Remove this line
]

You should remove the line with the dependency on ‘catalogue’ because you have to remove the field that depended on it.

Step 3: Remove ‘catalogue’ from INSTALLED_APPS

Now safely remove ‘catalogue’ from the INSTALLED_APPS list in Django project’s settings.

Step 4: Apply the Migrations

Finally, run the migration again to apply the changes:

python manage.py migrate

Step 5: Clean Up Oscar-Specific Code

With the ‘catalogue’ app and the product field dependency removed, you cab start cleaning up any other Oscar-specific code in my project.

By following these steps, you will be most likely be able to safely remove the ‘catalogue’ app (Oscar) from your project without encountering the "lazy reference" error. Remember to back up your data and use version control (e.g., Git) to track changes during this process. Also, be cautious when removing third-party dependencies, as it may impact other parts of your project.

👤Bikash Timsina

Leave a comment