web-dev-qa-db-fra.com

Django 1.7 - makemigrations ne détecte pas les changements

Comme le titre l'indique, je n'arrive pas à faire fonctionner les migrations.

À l'origine, l'application était inférieure à 1.6. Je comprends donc que les migrations n'y seront pas initialement. En fait, si je lance python manage.py migrate, je reçois:

Operations to perform:
  Synchronize unmigrated apps: myapp
  Apply all migrations: admin, contenttypes, auth, sessions
Synchronizing apps without migrations:
  Creating tables...
  Installing custom SQL...
  Installing indexes...
Running migrations:
  No migrations to apply.

Si je modifie un modèle dans myapp, le message indique toujours non migré, comme prévu.

Mais si je lance python manage.py makemigrations myapp je reçois:

No changes detected in app 'myapp'

Peu importe ce que je fais ou la manière dont j'exécute la commande, l'application ne détecte jamais les modifications et n'ajoute aucun fichier de migration à l'application.

Existe-t-il un moyen de forcer une application sur les migrations et de dire essentiellement "Ceci est ma base pour travailler avec" ou quoi que ce soit? Ou est-ce que je manque quelque chose?

Ma base de données est une base PostgreSQL si cela peut aider.

126
TyrantWave

Ok, on dirait que j'ai raté une étape évidente, mais l'affiche au cas où quelqu'un d'autre ferait de même.

Lors de la mise à niveau vers la version 1.7, mes modèles sont devenus non gérés (managed = False). Je les avais déjà sous la forme True, mais il semble que cela ait été annulé.

La suppression de cette ligne (Pour définir True par défaut), puis l’exécution de makemigrations ont immédiatement transformé un module de migration en place. makemigrations ne fonctionnera pas sur les tables non gérées (ce qui est évident après coup)

25
TyrantWave

Si vous passez d'une application existante créée dans Django 1.6, vous devez effectuer une étape préalable (telle que je l'ai découverte) répertoriée dans la documentation:

python manage.py makemigrations your_app_label

La documentation n'indique pas clairement que vous devez ajouter le libellé de l'application à la commande, car la première chose qu'il vous dit de faire est python manage.py makemigrations, ce qui échouera. La migration initiale est effectuée lorsque vous créez votre application dans la version 1.7, mais si vous veniez de la version 1.6, cela n'aurait pas été effectué. Reportez-vous à la 'Ajout de la migration aux applications' dans la documentation pour plus de détails.

173
drojf

Ma solution n'était pas couverte ici, alors je la poste. J'avais utilisé syncdb pour un projet, juste pour le mettre en marche. Puis, lorsque j'ai essayé de commencer à utiliser les migrations Django, cela les a simulés au début, puis je me suis dit que c'était «OK», mais rien ne se passait dans la base de données.

Ma solution consistait simplement à supprimer tous les fichiers de migration de mon application, ainsi que les enregistrements de base de données pour les migrations d'application dans la table Django_migrations.

Ensuite, je viens de faire une migration initiale avec:

./manage.py makemigrations my_app

suivi par:

./manage.py migrate my_app

Maintenant, je peux effectuer des migrations sans problème.

18
Grant Eagon

D'accord avec @furins. Si tout semble être en ordre et que ce problème se pose, vérifiez s'il existe une méthode de propriété ayant le même titre que l'attribut que vous essayez d'ajouter à la classe Model. 

  1. Supprimez la méthode avec un nom similaire à l'attribut que vous ajoutez.
  2. manage.py makemigrations my_app
  3. manage.py migrer mon_app
  4. Ajouter les méthodes de retour.
15
Prashant Nair

C'est une sorte d'erreur stupide à faire, mais le fait d'avoir une virgule supplémentaire à la fin de la ligne de déclaration de champ dans la classe de modèle rend la ligne sans effet.

Cela arrive quand vous copiez-collez le def. de la migration, qui est elle-même définie comme un tableau.

Cela aiderait peut-être quelqu'un :-)

11
Iman Akbari

Peut-être que je suis trop tard, mais avez-vous essayé d'avoir un dossier migrations dans votre application contenant un fichier __init__.py

8
rrrub

La suite a fonctionné pour moi:

  1. Ajoutez le nom de l'application à settings.py
  2. utilisez 'python manage.py makemigrations'
  3. utilisez 'python manage.py migrate'

A travaillé pour moi: Python 3.4, Django 1.10

7
Pranshu Gupta

La réponse est sur ce post stackoverflow, par cdvv7788 Migrations dans Django 1.7

Si vous migrez cette application pour la première fois, vous devez utiliser:

manage.py makemigrations myappname Une fois que vous faites cela, vous pouvez faire:

manage.py migrate Si votre application était dans la base de données, modifiez son modèle et sa ne met pas à jour les modifications sur makemigrations que vous n'avez probablement pas migré encore. Remettez votre modèle à sa forme d'origine, exécutez le fichier Première commande (avec le nom de l'application) et migrer ... il va simuler. Une fois que vous faites cela pour reporter les modifications sur votre modèle, exécuter makemigrations et migrer à nouveau et cela devrait fonctionner.

J'avais exactement le même problème et cela fonctionnait parfaitement.

J'avais déplacé mon application Django sur cloud9 et, pour une raison quelconque, je n'ai jamais capturé la migration initiale.

7
MicahT

Les personnes comme moi qui n'aiment pas les migrations peuvent utiliser les étapes ci-dessous.

  1. Supprimer les modifications que vous souhaitez synchroniser.
  2. Exécutez python manage.py makemigrations app_label pour la migration initiale.
  3. Exécutez python manage.py migrate pour créer des tables avant d'apporter des modifications.
  4. Collez les modifications que vous supprimez à la première étape.
  5. Exécutez les étapes 2. et 3..

Si vous avez confondu l'une de ces étapes, lisez les fichiers de migration. Modifiez-les pour corriger votre schéma ou supprimez les fichiers indésirables, mais n'oubliez pas de modifier les dépendances du prochain fichier de migration;)

J'espère que cela aidera quelqu'un à l'avenir.

6
Deniz Kaplan

Cela aidera peut-être quelqu'un. J'utilisais une application imbriquée. project.appname et j'avais réellement project et project.appname dans INSTALLED_APPS. La suppression du projet dans INSTALLED_APPS a permis de détecter les modifications.

6
jaywhy13

Vous souhaitez vérifier le settings.py dans la liste INSTALLED_APPS et vous assurer que toutes les applications avec des modèles y sont répertoriées.

Exécuter makemigrations dans le dossier du projet signifie que le système cherchera à mettre à jour toutes les tables relatives à toutes les applications incluses dans settings.py pour le projet. Une fois que vous l'avez incluse, makemigrations inclura automatiquement l'application (cela économise beaucoup de travail, vous n'avez donc pas besoin d'exécuter makemigrations app_name pour chaque application de votre projet/site).

5
Sticky

Juste au cas où vous auriez un champ spécifique non identifié par makemigrations: cochez deux fois si vous avez une propriété du même nom.

exemple:

field = Django.db.models.CharField(max_length=10, default = '', blank=True, null=True)

# ... later

@property
def field(self):
    pass

la propriété "écrasera" la définition du champ afin que les modifications ne soient pas identifiées par makemigrations

4
furins

Ajouter cette réponse parce que seule cette méthode m'a aidé.

J'ai supprimé le dossiermigrationsrun makemigrations and migrate.
Il disait encore: Aucune migration à appliquer.

Je suis allé dans le dossiermigrateet j'ai ouvert le dernier fichier créé.
commente la migration que je voulais (elle a été détectée et entrée là-bas)
et exécutez migrate à nouveau.

Cela consiste essentiellement à modifier manuellement le fichier de migration.
Ne le faites que si vous comprenez le contenu du fichier.

4
Jithin Pavithran

Assurez-vous que votre modèle n'est pas abstract. En fait, j'ai commis cette erreur et cela a pris du temps, alors j'ai pensé la poster.

4
Mark

Avez-vous utilisé schemamigration my_app --initial après avoir renommé l'ancien dossier de migration? Essayez-le Pourrait fonctionner. Sinon, essayez de recréer la base de données et faites syncdb + migrate. Cela a fonctionné pour moi ...

3
Alex Vidis

Peut-être que cela peut aider quelqu'un, j'ai eu le même problème.

J'ai déjà créé deux tables avec la classe de sérialiseur et les vues ..__ Donc, lorsque je voulais mettre à jour, j'avais cette erreur.

J'ai suivi ces étapes:

  1. J'ai fait .\manage.py makemigrations app
  2. J'ai exécuté .\manage.py migrate
  3. J'ai effacé les deux tables de mon models.py
  4. J'ai effacé toute référence à mes tables du sérialiseur et de la classe de vue.
  5. J'ai exécuté les étapes 1 et 2.
  6. J'ai récupéré mes modifications juste dans le models.py
  7. J'ai exécuté à nouveau l'étape 5.
  8. J'ai restauré tous mes changements.

Si vous travaillez avec Pycharm, l'histoire locale est très utile.

1
winter

J'ai eu le même problème d'avoir à exécuter makemigrations deux fois et toutes sortes de comportements étranges. Il s’est avéré que la source du problème était que j’utilisais une fonction pour définir les dates par défaut dans mes modèles, de sorte que les migrations détectaient un changement à chaque exécution de makemigrations. La réponse à cette question m'a mis sur la bonne voie: Évitez les migrations pour recréer le champ de date

1
PhoebeB

J'ai récemment mis à jour Django de 1,6 à 1,8 et je n'ai eu que peu d'applications et de migrations. J'ai utilisé south et schemamigrations pour créer des migrations dans Django 1.6, qui est supprimé dans Django 1.8. 

Lorsque j'ai ajouté de nouveaux modèles après la mise à niveau, la commande makemigrations ne détectait aucune modification. Et puis j'ai essayé la solution proposée par @drojf (1ère réponse), cela a bien fonctionné, mais n'a pas réussi à appliquer une fausse migration initiale (python manage.py --fake-initial). Je faisais cela car mes tables (les anciennes) étaient déjà créées.

Enfin, cela a fonctionné pour moi, j'ai supprimé de nouveaux modèles (ou modifications de modèles) de models.py, puis supprimé (ou renommé pour la sauvegarde de sécurité) le dossier de migration de toutes les applications et exécuté python manage.py makemigrations pour toutes les applications, puis python manage.py migrate --fake-initial. Cela a fonctionné comme un charme. Une fois que la migration initiale est créée pour toutes les applications et que la fausse migration initiale est fictive, elle ajoute de nouveaux modèles et suit le processus habituel de makemigrations et migre sur cette application. Les changements ont été détectés maintenant et tout s'est bien passé.

Je viens de penser à le partager ici, si quelqu'un rencontrait le même problème (ayant schemamigrations du sud pour leurs applications), cela pourrait les aider :)

1
RaghavHarpale
./manage makemigrations
./manage migrate

Les migrations suivent les modifications apportées à la base de données. Ainsi, si vous passez de non géré à géré, vous devez vous assurer que votre table de base de données est à jour en ce qui concerne le modèle que vous utilisez.

Si vous êtes toujours en mode dev, j'ai personnellement décidé de supprimer les fichiers de migration de mon IDE ainsi que de la table Django_migrations relative à mon modèle et de réexécuter la commande ci-dessus.

N'OUBLIEZ PAS: si votre migration se termine par _001 dans votre IDE & _003 dans votre base de données. Django ne verra que si vous avez une migration se terminant par _004 pour quoi que ce soit à mettre à jour.

Les 2 (migrations de codes et de bases de données) sont liés et fonctionnent en tandem.

Bonne codage.

1
A H Bensiali

Cela aidera peut-être quelqu'un.

J'ai supprimé mon models.py et j'attendais que makemigrations crée des instructions DeleteModel.

N'oubliez pas de supprimer*.pycfiles!

1
Sebastian Wagner

Ajout de cette réponse car aucun des autres éléments ci-dessus ne fonctionnait pour moi.

Dans mon cas, quelque chose d'encore plus étrange se passait (Django 1.7 Version), dans mon models.py, une ligne "extra" se trouvait à la fin de mon fichier (elle était vide ligne) et lorsque j’ai exécuté la commande python manage.py makemigrations, le résultat était: "aucun changement détecté".

Pour résoudre ce problème, j'ai supprimé cette "ligne vide" qui se trouvait à la fin de mon fichier models.py et j'ai à nouveau exécuté la commande. Tout a été corrigé et toutes les modifications apportées à models. py ont été détectés!

0
Huskie

Eu le même problème .__ Assurez-vous que quelles que soient les classes que vous avez définies dans models.py, vous devez hériter de la classe models.Model.

class Product(models.Model):
    title = models.TextField()
    description = models.TextField()
    price = models.TextField()
0
Sonu Kumar

Vous devrez peut-être simuler les migrations initiales à l'aide de la commande ci-dessous.

python manage.py migrate --fake-initial
0
dtar