web-dev-qa-db-fra.com

La colonne Django "nom" de la relation "Django_content_type" n'existe pas

L'erreur suivante persiste lors de la migration (migration python manage.py):

Django.db.utils.ProgrammingError: column "name" of relation "Django_content_type" does not exist

J'ai fait ce qui suit pour essayer de le réparer mais sans succès:

  1. J'ai supprimé tous les fichiers de migration pour chaque modèle
  2. supprimé tous les enregistrements dans Django_migrations
  3. lancez python manage.py migrate --fake-initial

Lancer 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

Merci pour l'aide. 

djangodjango-models
20
Yannick

Cela s'est produit lors de la mise à niveau vers la version 1.8 et de la migration de MySQL vers Postgres.

Je ne peux pas expliquer pourquoi l'erreur se produit, mais j'ai pu contourner le problème en ajoutant manuellement la colonne:

  1. Supprimer toutes les migrations

  2. Supprimer des enregistrements de Django_migrations

  3. Ajouter manuellement la colonne name: 

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

  4. Exécuter une fausse initiale: $ python manage.py migrate --fake-initial

Edit 12/2016 : Je vous recommande cette solution de contournement, plus adaptée aux projets personnels ou aux environnements locaux et non aux environnements de production. Évidemment, si vous vous souciez de votre histoire de migration, ce n'est pas la voie à suivre.

23
John M.

J'ai rencontré le même problème aujourd'hui, et j'aimerais ajouter un résumé du problème et comment le résoudre:

Source du problème:

Django 1.8 a modifié ses structures de base de données internes et la colonne name n’existe plus dans la base de données (voir provient de l’attribut verbose_name du modèle ). 

Pour remédier à cela, une migration contenttypes-0002_remove_content_type_name est automatiquement créée. 

Habituellement, toutes vos migrations devraient être appliquées et cela devrait être enregistré dans la table Django_migrations et tout devrait bien se passer. 

Si, par exemple, vous avez effectué une sauvegarde de votre base de données à l'aide de dumpdata, effacé (vidé) tout le contenu de la base de données et chargé le vidage avec loaddata, votre table Django_migrations reste vide. 

Ainsi, migrate essaie d'appliquer à nouveau toutes les migrations (même si vos tables sont existantes) et échoue lorsqu'il essaie de supprimer la colonne non existante name. 

Vous pouvez vérifier si cette situation s'applique en vérifiant votre table Django_migrations ou, bien plus conventionnel, en exécutant python manage.py showmigrations. Si votre situation ressemble à 

contenttypes
 [X] 0001_initial
 [X] 0002_remove_content_type_name

vous allez bien (ou vous avez un problème différent), au cas où cela ressemble à ceci

contenttypes
 [ ] 0001_initial
 [ ] 0002_remove_content_type_name

vous avez rencontré la situation décrite ci-dessus. Veuillez vérifier que votre base de données contient toutes les tables et toutes les colonnes (à l'exception des modifications que vous souhaitez appliquer avec votre migration ayant échoué).

Que faire/Solution pas à pas:

Donc, notre structure de base de données est correcte (à l'exception des modifications que vous souhaitiez appliquer avec votre migration échouée), mais Django/migrate ne le sait tout simplement pas. Alors faisons quelque chose à ce sujet:

  1. Indiquez à Django que toutes les migrations de types de contenu ont été appliquées: manage.py migrate --fake contenttypes. Si vous souhaitez vérifier, exécutez showmigrations.

  2. N'indiquons pas à Django que toutes les migrations antérieures à celle que vous souhaitez appliquer ont été appliquées. Pour cela, vous avez besoin du numéro de migration indiqué par showmigrations. Par exemple, si votre situation ressemble à

    my_app
 [ ] 0001_initial
 [ ] 0002_auto_20160616_0713

    et votre migrate a échoué lors de l'application 0002_auto_20160616_0713, la dernière migration appliquée avec succès dans votre base de données était 0001_initial. Wen applique ensuite l'entrée dans la table Django_migrations- par python manage.py migrate --fake my_app 0001 (rappelez-vous que le nombre de migrations est suffisant). migrate simulera automatiquement toutes les autres migrations dépendantes si nécessaire. 

  3. Maintenant, nous pouvons appliquer la migration missiong, et cette fois nous devons le faire pour de vrai et non faux! Donc, nous courons python manage.py migrate my_app. Cela devrait modifier la base de données selon les besoins. 

    Si votre dernière migration dépend d'autres migrations qui n'ont pas encore été falsifiées, vous devez les simuler au préalable.

  4. Double vérification et nettoyage: utilisez à nouveau showmigrations pour vérifier si toutes les migrations ont été appliquées. S'il y a des migrations ouvertes, simulez-les en utilisant python manage.py migrate --fake.

Choses que vous ne devriez pas faire

  • supprimer toutes les migrations - dans un contexte de production, cela pourrait ne pas être applicable car elles pourraient contenir du travail de migration de données qui ne devrait pas être perdu.
  • ajoutez manuellement la colonne name à contenttypes - elle sera supprimée par la suite lorsque la migration sera appliquée. Ok, c'est un hack qui marche, mais ça ne règle pas le problème.

Les choses que vous devriez faire

Essayez de comprendre comment vous êtes entré dans cette situation et de trouver des moyens de l'éviter. 

Mon problème était que j'avais différentes bases de données pour mon projet (sqlite pour des tests de développement rapides, des postgres locaux pour des tests sur le monde réel, des postgres distants pour la production) et que je voulais copier le contenu de l'un à l'autre. 

29
OBu

J'avais cette erreur après avoir décidé de supprimer les migrations du contrôle de version (git) et de créer une nouvelle base de données à partir de zéro.

Quelque chose qui a fonctionné pour moi (bien que pour être honnête, je ne sache pas pourquoi) a été d'exécuter 'makemigrations' pour chaque application. ainsi, 'python manage.py makemigrations app1', 'python manage.py makemigrations app2', etc. pour chaque application Django.

Finalement, j'ai juste lancé 'python manage.py migrate', je me suis croisé les doigts et ça a fonctionné.

Toute idée de comment/pourquoi cela fonctionnerait serait utile.

4
Joe Fusaro

Je sais que c’est une vieille question, mais cela pourrait aider quelqu'un… Je me faisais aussi cette erreur. Le problème était que content_types avait une migration appelée 0002_remove_content_type_name qui supprimait la colonne "nom".
Après avoir supprimé les données de migration de la table et du dossier, cette procédure me convient:

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

Si vous êtes sûr que le reste de votre base de données reflète votre migration, vous pouvez utiliser:

./manage.py migrate --fake

Voir le résultat avec:

./manage.py showmigrations

Après cela, toutes vos migrations devraient être marquées et tout devrait bien aller.

3
Descio

J'ai eu le même problème mais j'ai pu le résoudre en ajoutant ceci dans mes dépendances de migration:

('contenttypes', '0002_remove_content_type_name')

J'espère que ça aide!

1
danielmaxx

Une autre variante qui a fonctionné pour moi (à partir d'une base de données vierge) était:

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

Une variante qui DID ne fonctionnait PAS était:

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

Ou plutôt, la séquence fonctionnerait apparemment la première fois, mais ne fonctionnerait pas la deuxième fois, se plaignant alors que Django_content_type n'existait pas. 

La variante de travail (première ligne 2) ci-dessus semble être idempotente.

(édité: pour supprimer la deuxième ligne redondante de la version de travail d'origine à 3 lignes)

0
jonseymour