Django column "name" of relation "django_content_type" does not exist

Encountered this when upgrading to 1.8 and migrating from MySQL to Postgres.

I can't explain why the error occurs, but I was able to get around it by manually adding the column:

1. Delete all migrations

2. Delete records from django_migrations

3. Manually add name column:

   ALTER TABLE django_content_type ADD COLUMN name character varying(50) NOT NULL DEFAULT 'someName';
   

4. Run fake initial: $ python manage.py migrate --fake-initial

Edit 12/2016: I'm recommending this as a workaround, more suited for personal projects or local environments and not production environments. Obviously if you care about your migration history this is not the way to go.

I ran into the same problem today, and I would like to add a summary of the problem and how to resolve it:

Source of the Problem:

Django 1.8 changed its internal database structures and the column name is no longer existing in the data base (see is taken from the verbose_name attribute of the model).

To adress this, a migration contenttypes-0002_remove_content_type_name is automatically created.

Usually, all your migrations should have been applied and this should be recorded in the table django_migrations and all should be fine.

If you for example did a backup of your database using dumpdata, cleared (flushed) all database content, and loaded the dump with loaddata, your django_migrations table remains empty.

Thus, migrate tries to apply all migrations again (even though your tables are existing), and it fails when it tries to remove the non-existing column name.

You can check whether this situation applies by either checking your django_migrations table, or - much more conventient - by running python manage.py showmigrations. If your situation looks like

contenttypes
 [X] 0001_initial
 [X] 0002_remove_content_type_name

you are fine (or in fact you are having a different problem), in case it looks like this

contenttypes
 [ ] 0001_initial
 [ ] 0002_remove_content_type_name

you ran into the situation described above. Please double-check, that your database contains all tables and all colums (except for the changes you wanted to apply with your failed migration).

What to do / Step by Step Solution:

So our database structure is ok (except for the changes you wanted to apply with your failed migration), but Django / migrate just does not know about it. So let us do something about it:

1. Tell Django, that all contenttypes migrations have been applied:
   manage.py migrate --fake contenttypes
   If you want to double-check, run showmigrations.

2. Now let's tell Django that all migrations prior to the one you want to apply have been applied. For this, you need the migration number as shown by showmigrations. For example, if your situation looks like

   my_app
    [ ] 0001_initial
    [ ] 0002_auto_20160616_0713
   

   and your migrate failed while applying 0002_auto_20160616_0713, the last successfully applied migration in your database was 0001_initial. We then enforce the entry in the django_migrations-table by
   python manage.py migrate --fake my_app 0001
   (remember that the number of migrations is sufficient). migrate will automatically fake all other dependent migrations if necessary.

3. Now we can apply the missiong migration, and this time we have to do it for real and not faked! So we run python manage.py migrate my_app. This should alter the database as required.

   If your last migration depends on other migrations which have not been faked already, you should fake them beforehand.

4. Double-check and clean-up: Use showmigrations again to check whether all migrations mave been applied. If there are open migrations, fake them by using python manage.py migrate --fake.

Things you should not do

• delete all migrations - in a production setting this might just not be applicable because they might contain some work for migrating data which should not be lost.
• manually add the column name to contenttypes - it will be removed afterwards when the migration is applied. Ok, it's a working hack, but it does not adress the problem.

Things you should do

Try to figure out how you got into this situation and find ways to avoid it.

My problem was, that I had different databases for my project (sqlite for fast development testing, local postgres for real world testing, remote postgres for production) and I wanted to copy content from one to an other.