You ran makemigrations, then migrate and yet Django dares to throw an error? Incomparable betrayal! Let’s look through several cases.

Sidenote

For ages encountering migrations errors, I have been wipin the entire database and migrations files. Until one day an error occurred at a production server. There was no other option but to calm down and learn how to fix it.

🧸 Relation does not exist 1: not applied by you or Django

Run the command showmigrations and look at the output. If you see something like this:

firstapp
 [X] 0001_initial
 [X] 0002_auto_20190819_2019
 [X] 0003_auto_20190827_2311
 [ ] 0004_testunit

That means that the 0004 migrations was not applied, so just run migrate. If it stays misapplied or to avoid wasting time you can run this:

migrate firstapp 0004_testunit

If not, look further.

💔 Relation does not exist 2: You removed a migration’s file

Sidenote

The point of each migrations is to find the difference between the last version of the database structure and the current one. But Django does not look at the database itself, it compares your current models.py files with a virtual database made from migrations.py files. Then Django writes the changes down in new migrations files. And only with migrate you apply these changed to the database.

So if you remove something from migrations/ folder, the database will stay the same, but the Django’s idea of it won’t.

Case

So, you added a field type to a class Tag:

class Tag(models.Model)
   name = models.CharField(max_length=100)
   type = models.CharField(max_length=100)

You made a migrations, say, number 0002, it contains adding type field. Then you removed the migrations. After that, you made some changes, lived your best live, and decided to make migrations again.

Django will include creation of the type field to the migrations again. Therefore applying this migrations will give you an error:

ProgrammingError: column "tag_type" of relation "tag" already exists

How to Solve it 🧰

1. From migration file 0002_something.py remove the line about creating the type field.

from django.db import migrations, models


class Migration(migrations.Migration):

    dependencies = [
        ('firstapp', '0002_something'),
    ]

    operations = [
        ...
        # This .AddField below:
        migrations.AddField(
            model_name='tag',
            name='type',
            field=models.Charfield(max_length),
        ),
        ...
    ]

2. Migrate the 0002_something.py file:

migrate firstapp 0002_something

3. Make a new migration (it must only contain creating the type field):

makemigrations

4. Fake apply it like this:

 migrate firstapp 0003_something_two --fake

🔨 Relation does not exist 2: Renaming a field was not applied

This mysterious thing happened. I renamed type to type_name and I have a migrations that states it:

...    
    operations = [
        migrations.RenameField(
            model_name='tag',
            old_name='type',
            new_name='type_name',
        ),
    ]
...

And yet I get this error:

ProgrammingError at /test relation "firstapp_tag_type_name" does not exist

Possible culprit (myself and mass replace) a.k.a Sloppy Development installment

While changing names in the whole project automatically, I also unwillingly changed them in the migrations files. It is a great temptation to remove it all at once, but be careful. That may be the problem.

How to Solve it 🧰

Attempt #1: Order is wrong

The type field may have been altered before it was created because of the mass replace.

Try finding the whole life cycle of type field in your migrations – where it was added, where it was altered etc.

Attempt #2: Remove Migration file concerning the field

Remove every mention of the type field in migrations’ files (in operation). Then do whatever you want (rename it etc.) and make a migration again.

If the change is the only one in a migrations file, remove it all together.

You can remove the whole migration file, if it only contains type field manipulations. But be careful and alter dependencies for the following migration file (replace the deleted file’s name with the one before it).

Say, migrations’s files are 0002_something_before.py, 0003_something.py (removed) and 0004_brave_new.py.

So, after deleting 0003_something.py, in 0004_brave_new.py file:

dependencies = [
    ('firstapp', '0003_something'),
]

Replace 0003_something.py with0002_something_before:

dependencies = [
    ('firstapp', '0002_something_before'),
]

Otherwise you will get an error like this:

django.db.migrations.exceptions.NodeNotFoundError: Migration firstapp.0003_something_something dependencies reference nonexistent parent node 

Then, makemigrations and migrate.

Attempt #3: Remove every mention of the problematic field

If simply removing a migration and making another one doesn’t help…

Embrace yourself and remove every mention of type field. For my personal project, that inspired this post, it was quite time consuming.

However, as I see it now, you can’t just remove the field and make migrations of that, because type does not exist in the database. However, I can’t answer why.

You need to remove it from everywhere.

Then, makemigrations must show nothing, and the error won’t make am appearance.

🚫 Why you shouldn’t remove migrations

Summing up, Django does not care about database itself, except for when it returns errors. So Django’s idea of the database is made of migrations it have. That’s why when you run makemigrations, you get errors about migration files.

After applying new migrations, you will start getting all sorts of surprises: InvalidCursorName cursor does not exist or good old ProgrammingError: column does not exist and ProgrammingError: column of relation already exists.

Take my advice – don’t remove migrations because of migration errors, better learn how to work with them. Because in production you won’t be able to flush the database without a trouble (you kind of can, but you will need to insert missing data afterwards).

But if you did remove migrations…

Oh, been there.

I can say one thing – you will need to keep reversing changes to the database until you don’t get any more errors. And then make this changes again the same way I showed you here. And while in most cases Attempt #3 works, some day it may fail you.

One day I will emulate this and come back and update this post with a quick solution, but now I am triggered enough by just the mention of it.

Transforming one field to another

You can transform pretty much everything with an exception.

Adding a through table to M2M relation (or backwards)

Usually you want to add a through table to store additional data about the relation, not remove it. Either way, Django won’t allow this transition.

Say, Django can remove all the additional data, but constraints like unique_together can ruin your architecture. So you need to do it manually.