web-dev-qa-db-fra.com

Django 1.7 - "Aucune migration à appliquer" lors de l'exécution de la migration après makemigrations

J'utilise Django1.7 avec Mezzanine. Je crée un profil simple (selon la documentation Mezzanine) stocké dans des "profils" distincts de l'application:

class RoadmapProfile(models.Model):
    user = models.OneToOneField("auth.User")
    fullname = models.CharField(max_length=100, verbose_name="Full name")

La création de migrations renvoie:

  Migrations for 'profiles':
      0001_initial.py:
        - Create model RoadmapProfile

Quand j'exécute "migrer des profils":

Operations to perform:
  Apply all migrations: profiles
Running migrations:
  No migrations to apply.

Le problème est que, lorsque j'essaie d'ouvrir une page liée à mezzanine.accounts (par exemple, mettre à jour un compte), le système plante:

OperationalError at /accounts/update/

no such column: profiles_roadmapprofile.fullname

Qu'est-ce que j'ai mal fait?

pythondjango
45
matousc

On dirait que votre migration initiale a été falsifiée parce que la table existait déjà (probablement avec un schéma obsolète):

https://docs.djangoproject.com/fr/1.7/topics/migrations/#adding-migrations-to-apps

"Cela créera une nouvelle migration initiale pour votre application. Désormais, lorsque vous exécuterez migrate, Django détectera que vous avez une migration initiale et Que les tables qu'il souhaite créer existent déjà, et marquera la migration telle qu'appliquée déjà. "

Sinon, vous obtiendrez une erreur sans table :)

[edit] Avez-vous nettoyé la table appliquée-migrations? C'est également une cause commune pour les migrations non appliquées. 

25
ACimander
  1. Dans la base de données MySQL, supprimez la ligne 'profiles' de la table 'Django_migrations'.
  2. Supprimez tous les fichiers de migration dans le dossier migrations.
  3. Réessayez les commandes python manage.py makemigrations et python manage.py migrate.
98
Zulfugar Ismayilzadeh

Je suis un débutant à Django et je traversais le même problème. Ces réponses n'ont pas fonctionné pour moi. Je voulais partager comment j'ai résolu le problème, cela permettrait probablement à quelqu'un de gagner beaucoup de temps.

Situation:

J'apporte des modifications à un modèle et je souhaite appliquer ces modifications à la base de données.

Ce que j'ai fait:

Exécuter sur Shell:

python manage.py makemigrations app-name
python manage.py migrate app-name

Qu'est-il arrivé:

  • Aucune modification n'est apportée dans la base de données.

  • Mais quand je vérifie le schéma de base de données, il ne reste plus que l'ancien

Raison:

  • Lorsque j'exécute python manage.py migrate app-name, Django vérifie dans la table Django_migrations de la base de données quelles sont les migrations déjà appliquées et ignorera ces migrations.

Ce que j'ai essayé:

Supprimez l'enregistrement avec app = "my-app-name" de cette table (delete from Django_migrations where app = "app-name"). Effacer mon dossier de migration et exécuter python manage.py makemigration my-app-name, puis python manage.py migrate my-app-name. Cela a été suggéré par la réponse la plus votée. Mais ça ne marche pas non plus.

Pourquoi?

Puisqu'il y avait une table existante et que je crée une "migration initiale", Django décide que la migration initiale a déjà été appliquée (car il voit que la table existe déjà). Le problème est que la table existante a un schéma différent.

Solution 1:

Supprimez la table existante (avec l'ancien schéma), effectuez les migrations initiales et appliquez-la à nouveau. Cela fonctionnera (cela a fonctionné pour moi) car nous avons une "migration initiale" et il n'y avait pas de table du même nom dans notre base de données. (Astuce: j'ai utilisé python manage.py migrate my-app-name zero pour supprimer rapidement les tables de la base de données)

Un problème? Vous souhaiterez peut-être conserver les données dans la table existante. Vous ne voulez pas les laisser tomber et perdre toutes les données.

Solution 2:

  1. Créez une migration initiale avec le même schéma que la table existante, en procédant comme suit:

    • Modifiez votre fichier models.py pour qu'il corresponde à la table actuelle de votre base de données.

    • Supprimer tous les fichiers dans "migrations"

    • Exécuter python manage.py makemigrations your-app-name

  2. Supprimez dans Django_migrations tous les champs avec Django_migrations.app = your-app-nameComment faire, cela dépend du DB que vous utilisez Exemple pour MySQL: delete from Django_migrations where app = "your-app-name";

  3. Modifiez votre fichier models.py pour qu'il corresponde au nouveau schéma (par exemple, le schéma dont vous avez besoin maintenant).

  4. Effectuer une nouvelle migration en exécutant python manage.py makemigrations your-app-name

  5. Exécuter python manage.py migrate your-app-name

Cela fonctionne pour moi. Et j'ai réussi à conserver les données existantes.

Plus de pensées:

La raison pour laquelle j'ai traversé tous ces problèmes est que j'ai supprimé les fichiers de some-app/migrations/(les fichiers de migration). Et par conséquent, ces fichiers de migration et ma base de données ne sont pas cohérents. J'essayerais donc de ne pas modifier ces fichiers de migration à moins de savoir vraiment ce que je fais.

28
phanhuy152

1- exécuter python manage.py makemigrations <appname> 

2- lancez python manage.py sqlmigrate <appname> <migrationname> - vous trouverez le nom de migration dans le dossier de migration sous appname (sans l'extension ".py" bien sûr)

3- copier tout le texte du résultat # toutes les commandes SQL générées
4- allez dans votre base de données, collez-la en tant que nouvelle requête et exécutez-la. 

maintenant toutes les modifications sont appliquées sur votre base de données 

9
masood

Dans mon cas, j'ai écrit comme ceci:

python manage.py makemigrations --empty yourappname

python manage.py migrate yourappname

ou:

Django garde une trace de toutes les migrations appliquées dans la table Django_migrations. Donc, supprimez toutes les lignes de la table Django_migrations qui sont liées à votre application, comme:

DELETE FROM Django_migrations WHERE app=' votre-app-nom '

et ensuite faire:

python manage.py makemigrationspython manage.py migrate

5
Leonardo Ramos
python manage.py migrate --fake APPNAME zero

Cela rendra votre migration fausse. Maintenant, vous pouvez exécuter le script migrate

python manage.py migrate APPNAME

Des tables seront créées et vous aurez résolu votre problème. A la vôtre !!!

3
Vignesh

Mon problème était qu'il n'y avait pas de fichier __init__.py dans le même dossier que les migrations. En ajoutant le __init__.py au dossier qui les contenait, manage.py migrate a trouvé et exécuté.

2
Eosis

Le problème ici est la fausse migration quelque part. Fondamentalement, dans votre base de données, la table créée à partir de votre modèle n’existe pas, même si elle existait quelque part dans le temps, en raison d’une ancienne mise à jour, quelle qu’elle soit. Le problème est que Django a déjà effectué ces migrations, de sorte que les tables DEVRAIENT exister pour par conséquent ignorer les migrations mais obtenir l'erreur "table_doesnt_exist" dans Admin.

Solution: 

1.- Assurez-vous de sauvegarder toutes les données de ce modèle. 

2.- Accédez à votre base de données et exécutez cette requête.

 SELECT * FROM Django_migrations;

3.- Obtenir l'id de la liste générée à partir de la requête. Ce sont des migrations que Django a migrées jusqu'à présent, par conséquent, les tables devraient exister. Dans votre cas, je chercherais une ligne nomméeroadmapprofile, car c'est le nom de votre modèle. 

4.- Maintenant, supprimons cette ligne de cette table en utilisant les identifiants, 

 DELETE FROM Django_migrations where Django_migrations.id in (value_id1, value_id2);

Remplacez valeur_id1 et valeur_id2 par les identifiants respectifs. Cela pourrait être un ou plusieurs, alors ne vous inquiétez pas si vous ne voyez pas plus d'un identifiant, cela signifie qu'un seul modèle existe sous l'application actuelle. 

5.- Migrer l'application à zéro 

 manage.py migrate <app_name> zero

6.- Supprimer tous les fichiers de migration dans le dossier des migrations d'applications

7.- Créer des migrations

 manage.py makemigrations

8.- Une fois que vous supprimez ces registres et exécutez manage.py migrate; Django sera obligé d'exécuter des migrations pour ces modèles en raison de "MIGRATIONS EXISTANTES" pour ces modèles.

 manage.py migrate

C'est tout. Vous ne devriez pas avoir de problèmes en suivant ces instructions. En passant, vous ne devriez pas perdre de données des autres modèles, car vous ne faites que migrer et mettre à jour des tables associées à ces modèles spécifiques.

1
Wolfgang Leon

@ phanhuy152 a la meilleure réponse. Juste pour ajouter mes deux centimes:

Sa solution est:

  1. Supprimer l'historique de migration dans la base de données
  2. Supprimer le dossier migrations
  3. Modifiez votre modèle pour qu'il soit cohérent avec DB avant votre modification.
  4. makemigrations pour restaurer l'état initial des fichiers de migration
  5. Ensuite, changez le modèle comme vous le souhaitez
  6. makemigrations encore
  7. migrate pour appliquer les mises à jour à la table.

Mais dans mon cas, j'ai plusieurs modèles dans le fichier models.py et à la dernière étape, Django se plaint de Table xxx already exists, car les fichiers de migration initiaux ont à nouveau l'intention de créer la table xxx, alors que nous ne le faisons pas (et ne voulons pas ) supprimer d'autres tables.

Dans ce cas, pour préserver les données, nous devons dire à Django de les laisser seules dans migrate. Nous faisons juste: (supposons que la classe A est celle que nous changeons, et que les classes B, C restent les mêmes):

models.py:

from Django.db import models

class A(models.Models):
    ...

class B(models.Models):
    class Meta:
        managed = False   # tell Django to leave this class alone

    ...

class C(models.Models):
    class Meta:
        managed = False   # tell Django to leave this class alone

Ajoutez ces lignes après avoir construit les migrations initiales.

Donc, le processus est maintenant: 

  1. ...
  2. ...
  3. ...
  4. ...
  5. Ajouter managed = False à d'autres classes
  6. makemigrations pour appliquer Meta changements. Vous verrez quelque chose comme:

sortie:

Migrations for 'backEnd':
  backEnd/migrations/0002_auto_20180412_1654.py
    - Change Meta options on toid
    - Change Meta options on tprocessasinc
    - Change Meta options on tservers
    - Change Meta options on tsnmpserver
  1. migrate pour les appliquer dans DB
  2. Changez votre modèle maintenant: ajoutez un champ, changez le type, etc.
  3. migrate encore.
  4. Supprimez la classe Meta pour permettre à Django de gérer à nouveau une autre classe. makemigrations, migrate encore.

Vous avez maintenant toute la structure et les données de vos modèles, sans perdre la pièce précédemment stockée dans la base de données.

0
WesternGun

J'ai eu le même problème. Assurez-vous que le dossier de migration de l'application est créé (YOURAPPNAME/migrations). Supprimez le dossier et entrez les commandes:

python manage.py migrate --fake
python manage.py makemigrations <app_name>
python manage.py migrate --fake-initial

J'ai inséré ces lignes dans chaque classe dans models.py:

class Meta:
    app_label = '<app_name>'

Cela a résolu mon problème.

0
Camila Andrade

Pour moi, aucune des solutions proposées n'a fonctionné. Il s’avère que j’utilisais paramètres différents pour la migration (manage.py) et l’exécution (wsgi.py). Les paramètres définis dans manage.py utilisaient un base de données locale; cependant, un base de données de production était utilisé dans les paramètres wsgi.py. Ainsi, une base de données de production était jamais migrée.

Django-admin migrate

pour la migration s’est avéré meilleur car il faut spécifier les paramètres utilisés comme ici .

  • Assurez-vous que lorsque migration, vous utilisez toujours la base de données identique comme When en cours d'exécution!
0
PrimozKocevar