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

I keep getting the following error when doing a migration (python manage.py migrate):

django.db.utils.ProgrammingError: column "name" of relation "django_content_type" does not exist

I've done the following to try and fix it but without success:

1. I've delete all the migrations files for each model
2. deleted all the records in django_migrations
3. run python manage.py migrate --fake-initial

Running Django 1.8.2.

python manage.py showmigrations
admin
 [ ] 0001_initial
auth
 [ ] 0001_initial
 [ ] 0002_alter_permission_name_max_length
 [ ] 0003_alter_user_email_max_length
 [ ] 0004_alter_user_username_opts
 [ ] 0005_alter_user_last_login_null
 [ ] 0006_require_contenttypes_0002
contenttypes
 [X] 0001_initial
 [ ] 0002_remove_content_type_name
hashtags
 [ ] 0001_initial
 [ ] 0002_hashtagvisit_user
posts
 [ ] 0001_initial
 [ ] 0002_auto_20150530_0715
sessions
 [ ] 0001_initial
users
 [ ] 0001_initial

Thanks for the help.

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.

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 know that is an old question, but this might help some one. I was getting this error too. The problem was that content_types had a migration called 0002_remove_content_type_name that remove the column "name".
After remove migration data from table and folder this steps works for me:

./manage.py makemigrations myappname
./manage.py migrate myappname
./manage.py migrate --fake contenttypes

If you have sure that the rest of your db reflect your migration, you can use:

./manage.py migrate --fake

See the result with:

./manage.py showmigrations

After that, all your migrations should be marked and you should be fine

I had the same problem but I was able to solve it by adding this into my migration dependencies:

('contenttypes', '0002_remove_content_type_name')

Hope it helps!

I was getting this error after we decided to remove migrations from version control (git) and create a new database from scratch.

Something that worked for me (although to be honest I'm not sure why) was to run 'makemigrations' for each app. so, 'python manage.py makemigrations app1', 'python manage.py makemigrations app2', and so on for each Django app.

Finally, I just ran 'python manage.py migrate', crossed my fingers, and it worked.

Any insight into how/why this worked would be helpful.

Another variant that worked for me (from a blank database) was:

./manage.py makemigrations myappname
./manage.py migrate

A variant which DID NOT work was:

./manage.py makemigrations myappname
./manage.py migrate myappname

Or, rather, the sequence would apparently work the first time, but would not work the second time, complaining then that django_content_type did not exist.

The working (first 2-line) variant above seems to be idempotent.

(edited: to remove redundant second line from original 3-line working version)

For me, I ran makemigrations for each of my INSTALLED_APPS with this command:

python manage.py makemigrations compressor

change compressor with your INSTALLED_APPS. then successfully migrated with this command:

python manage.py migrate

Some part of you code is trying to access the django_content_type table when it dose not exist, leading to a ProgrammingError. A work round would be to wrap that part in a try except. Sample

try:
    seller_content_type = ContentType.objects.get_for_model(Seller)
    add_seller_permission = Permission.objects.get(
        codename='add_seller',
        content_type=seller_content_type,
    )
except ProgrammingError:
    add_seller_permission = None

You can actually replace add_seller_permission = None with just pass, but the above helps if you are using the value somewhere else, so it remains available at least till the migration is done.

I had this error in a Django 3.2 project while running makemigrations (and/or migrate) on a fresh database. In this case, the issue was that I had a line that was running on import (e.g. at the module or class level) that accessed the ContentTypes, like this:

TERM_CONTENT_TYPE = ContentType.objects.get_for_model(Term)

Since the database hadn't been made during import, this always fails with the error above.

The solution in this scenario is to move any database-interacting like that into a method or other place that does not run during import.

I had a similar issue. How I ended up in this position was like others where i was moving databases from one server to another. What happened is i tried to fix a failed migration by deleting all the migration files. What this really did was delete the 0002_remove_content_type_name.py file as well and that is where this whole issue started for me.

This file lives in the \venv\Lib\site-packages\django\contrib\contenttypes\migrations folder. So it is tied direction to your virtual environment. The server i was copying the database to had its own virtual environment (never copied that) so it still had the 0002_remove_content_type_name.py file in the folder.

To django this looked like an unapplied migration. And since i scraped my migration table and all the migration files in my test server it always looked for that migration on my production server.

How i fixed this was copied the 0002_remove_content_type_name.py from my production server back to my test server and ran the fake migration. So now ever time i copy my test db to prod, this wont happen.

I also, highly do not recommend copying the database like i am doing as that is what got me in all this trouble in the first place.

The full solution in my case if i did not have a copy of this file already would be as follows:

1. Create a new virtual environment
2. Create a test django project from scratch
3. Copy the 0002_remove_content_type_name.py from the newly created virtual environment to the same location in my current project(\venv\Lib\site-packages\django\contrib\contenttypes\migrations)
4. run "python manage.py showmigrations" to ensure it is now listed
5. run "python manage.py contenttypes --fake

Now all future migrations should work as it will be listed in the migrations table again.

Note: If you have the same issue with Auth and Admin, do the same thing with the files. They are in their respective folders in the virtual environment. I believe admin has 3 migrations in total and auth has 11. I noticed these were gone after i fixed my content types issue.

well None of this actually worked for me so i just deleted my database in postgresql and created a new one then ran deleted my previous migrations folder and last did all the migrations all over and it everything works just fine