django admin error - Unknown column 'django_content_type.name' in 'field list'

Question

My django project had a working admin page, but all of the sudden I started receiving: \"Unknown column \'django_content_type.name\' in \'field list\'\" whenev

Answer 1

The fix in MySQL for us was to drop table django_content_type;

The notes from karthikr and moonchel led me to the fix. 1054 Unknown column errors were occurring after installing Django 1.8 into one virtualenv to try it out, and then trying to use the pre-existing Django 1.6 in a different virtualenv. MySQL got messed up.

Django 1.7/1.8 syncdb revised the django_content_type table removing the 'name' column from it.

+-----------+--------------+------+-----+---------+----------------+
| Field     | Type         | Null | Key | Default | Extra          |
+-----------+--------------+------+-----+---------+----------------+
| id        | int(11)      | NO   | PRI | NULL    | auto_increment |
| app_label | varchar(100) | NO   | MUL | NULL    |                |
| model     | varchar(100) | NO   |     | NULL    |                |
+-----------+--------------+------+-----+---------+----------------+

Django 1.6 syncdb creates the table with the 'name' column:
+-----------+--------------+------+-----+---------+----------------+
| Field     | Type         | Null | Key | Default | Extra          |
+-----------+--------------+------+-----+---------+----------------+
| id        | int(11)      | NO   | PRI | NULL    | auto_increment |
| name      | varchar(100) | NO   |     | NULL    |                |
| app_label | varchar(100) | NO   | MUL | NULL    |                |
| model     | varchar(100) | NO   |     | NULL    |                |
+-----------+--------------+------+-----+---------+----------------+

So drop the table and let syncdb recreate it as required for the Django version. Take a dump if nervous about dropping it: mysqldump -u <mysqladminname> -p <databasename> django_content_type > /tmp/django_content_type.dmp

Answer 2

Man I was having the same problem in a huge framework with about 45 Django apps and 12 ReactJS applications; let's go to the code that solved my case:

---

1 - first install the django packages that increase your native command options for manage.py and django in general; in addition to trying to REINSTALL by upgrading django to a new version if one is available --->

***"pip install -U django django-rest-framework-tricks django-shortcuts django-admin-shortcuts django_extensions";***

---

2 - when reading the error in detail I realized that some .pyc and init files were linked to the fact, so within the main project directory execute where the "manage.py" file is; we will clean, guarantee permissions and unlink all sections connected to the bank that may be disturbing the framework:

***"./manage.py clean_pyc", "./manage.py clear_cache", "./manage.py update_permissions", ". /manage.py clearsessions "***

---

3 - still within the same directory where the "manage.py" file is located if there is still a cache or temporary execution file stored, not deleted for any reason whatsoever; execute the command to force the elimination of these files that may be disturbing the framework:

***"sudo find. -name '* __ pycache__' -exec rm -rf {} + && \
sudo python manage.py makemigrations && \
sudo find. -path "* / migrations / *. py" -not -name "__init__.py" -delete && \
sudo find. -path "* / migrations / *. pyc" -delete; "***

---

4 - lastly a great but excellent command to force the reindexation of models and views with the framework and the database; IN MY CASE THE APPLICATIONS I WILL MAKE TO EXAMPLE SAO (GUI_CUBE_X and BUI_CUBE_Y), PUT THE NAME OF YOUR APPLICATION; you can put HOW MANY you want, it doesn't matter, but in the two steps q is used the name has to be replicated in the 2 processes to work:

***"
./manage.py makemigrations && \
./manage.py migrate --fake GUI_CUBE_X zero && \
./manage.py migrate --fake GUI_CUBE_Y zero && \
./manage.py showmigrations && \
./manage.py makemigrations && \
./manage.py migrate --fake GUI_CUBE_X && \
./manage.py migrate --fake GUI_CUBE_Y && \
./manage.py makemigrations && \
./manage.py migrate && \
./manage.py collectstatic --clear --force-color --no-input;
systemctl restart uwsgi;
systemctl restart nginx;
"***

---

5 - test your application again

"./manage.py runserver 0.0.0.0:8080"

... and SUCCESS !!! we are ready to continue the show dude lol !!!

Enviar feedback Histórico Salvas Comunidade

Answer 3

If you have Django installed locally and in your virtual environment, then make sure that the virtual environment is activated.

Answer 4

I had this same issue just now and it was related to different versions of django. I updated all of the machines working on my project to django 1.8 using pip install -U Django and everything worked fine after that.

Answer 5

it's not django error, it's MySQL. I just started a project, but changed django version from 1.8 to 1.7 and got this error. So, I droped all table and run migrate. But you don't need to drop all tables, just part, may be just one.

Answer 6

Caused by two different versions of Django being installed. I had the error when I had Django1.7 installed locally and 1.8 in a virtualenv.

pip uninstall django

for the local version, and then restarting manage.py runserver from within the virtualenv fixed the error for me.