Django column "name" of relation "django_content_type" does not exist
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:
-
Tell Django, that all contenttypes migrations have been applied:
manage.py migrate --fake contenttypes
If you want to double-check, runshowmigrations
. -
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 likemy_app [ ] 0001_initial [ ] 0002_auto_20160616_0713
and your
migrate
failed while applying0002_auto_20160616_0713
, the last successfully applied migration in your database was0001_initial
. We then enforce the entry in thedjango_migrations
-table bypython 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. -
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.
-
Double-check and clean-up: Use
showmigrations
again to check whether all migrations mave been applied. If there are open migrations, fake them by usingpython 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:
Delete all migrations
Delete records from
django_migrations
-
Manually add
name
column:ALTER TABLE django_content_type ADD COLUMN name character varying(50) NOT NULL DEFAULT 'someName';
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!