Django - makemigrations - Aucun changement détecté

138

J'essayais de créer des migrations dans une application existante à l'aide de la commande makemigrations mais elle affiche "Aucun changement détecté".

Habituellement, je crée de nouvelles applications à l'aide de la startappcommande, mais je ne l'ai pas utilisée pour cette application lorsque je l'ai créée.

Après le débogage, j'ai constaté qu'il ne crée pas de migration car le migrationspackage / dossier est absent d'une application.

Serait-il préférable de créer le dossier s'il n'y est pas ou si je manque quelque chose?

Dilraj
la source
13
Votre application a-t-elle été ajoutée à INSTALLED_APPS?
wolendranh
6
Oui, c'est dans l'application installée, pour la première fois, il vaut mieux l'utiliser makemigrations <myapp>comme l'a également souligné Alasdair.
Dilraj
1
Supprimer 'abstract = True' :)
GrvTyagi
«makemigrations» n'a pas fonctionné. 'makemigrations <myapp>' a travaillé
Aseem

Réponses:

267

Pour créer des migrations initiales pour une application, exécutez makemigrationset spécifiez le nom de l'application. Le dossier migrations sera créé.

./manage.py makemigrations <myapp>

Votre application doit être incluse en INSTALLED_APPSpremier (dans settings.py).

Alasdair
la source
15
Une idée de la raison pour laquelle ils nous forcent <parfois> à spécifier l'application?
maazza
40
@maazza, vous devez spécifier le nom de l'application si l'application n'a pas de migrationsdossier. Cela peut se produire si vous avez créé l'application manuellement ou si vous avez mis à niveau une ancienne version de Django qui n'avait pas de migrations.
Alasdair
13
@maazza En fait, vous avez besoin d'un package python (avec __init__.py) nommé «migrations» dans l'application.
Jibin
3
Cela ressemble à quelque chose que Django devrait gérer automatiquement.
duality_
1
@duality_ c'est par conception - Django ne suppose pas que vous souhaitiez des migrations pour votre application. S'il a créé des migrations pour toutes les applications, cela peut entraîner des erreurs lors de l'exécution migrate.
Alasdair
49

Mon problème (et donc sa solution) était encore différent de ceux décrits ci-dessus.

Je n'utilisais pas de models.pyfichier, mais j'ai créé un modelsrépertoire et my_model.pyj'ai créé le fichier là, où j'ai mis mon modèle. Django n'a pas pu trouver mon modèle, il a donc écrit qu'il n'y avait pas de migrations à appliquer.

Ma solution était: dans le my_app/models/__init__.pyfichier, j'ai ajouté cette ligne: from .my_model import MyModel

Karina Klinkevičiūtė
la source
Cela s'est avéré être la solution pour moi aussi, mais je ne comprends pas pourquoi. Quelqu'un a-t-il une idée de ce qui peut en être la cause?
Paul in 't Hout le
Django a un chemin par défaut où chercher vos modèles. Si la structure du projet est différente et que les modèles ne sont pas à leur place habituelle, ils doivent y être importés.
Karina Klinkevičiūtė
@ KarinaKlinkevičiūtė et si je dois supprimer de tels modèles?
Daniil Mashkin
@DaniilMashkin J'imagine que vous devrez également supprimer les importations. C'est l'un des moyens de structurer votre projet (pas le seul) et vous devez faire face aux tâches supplémentaires qui l'accompagnent si vous le choisissez :)
Karina Klinkevičiūtė
1
J'ai utilisé l'architecture «classique» pour les modèles, puis j'ai migré vers l'architecture «dossier modèles», et toute migration est toujours détectée sur mes modèles existants. Cependant, maintenant, lors de la création d'un nouveau modèle, j'ai ce problème. Votre solution fonctionne bien, mais cela laisse ma base de code un peu incohérente car parfois il y a une importation, parfois non. Il existe peut-être une meilleure solution. Je suppose que Django devrait proposer un paramètre avec une liste de dossiers à rechercher lorsque vous essayez de trouver de nouveaux modèles.
David D. le
44

Il existe plusieurs raisons possibles pour lesquelles django ne détecte pas ce qu'il faut migrer pendant la makemigrationscommande.

  1. dossier de migration Vous avez besoin d'un package de migrations dans votre application.
  2. INSTALLED_APPS Vous devez spécifier votre application dans le INSTALLED_APPSfichier .dict
  3. Lamakemigrations -v 3 verbosité commence par s'exécuter pour la verbosité. Cela pourrait éclairer le problème.
  4. Chemin complet Dans INSTALLED_APPSil est recommandé de spécifier le chemin complet de la configuration de l'application du module 'apply.apps.MyAppConfig'
  5. --settings, vous voudrez peut-être vous assurer que le fichier de paramètres correct est défini:manage.py makemigrations --settings mysite.settings
  6. spécifiez le nom de l'application, mettez explicitement le nom de l'application manage.py makemigrations myapp, ce qui réduit les migrations pour l'application seule et vous aide à isoler le problème.
  7. modèle meta check vous avez le droit app_labeldans votre modèle meta

  8. Déboguer django debug django core script. La commande makemigrations est assez simple. Voici comment le faire dans pycharm . modifier la définition de votre script en fonction (ex: makemigrations --traceback myapp)

Plusieurs bases de données:

  • Db Router lorsque vous travaillez avec django db router, la classe de routeur (votre classe de routeur personnalisée) doit implémenter la allow_syncdbméthode.

makemigrations crée toujours des migrations pour les changements de modèle, mais si allow_migrate () retourne False,

user1134422
la source
1
Couvrir de nombreux scénarios concernant le problème, devrait être la réponse acceptée.
Krishh
Autre possibilité: le mauvais nom est importé, c'est-à-dire importer un champ à partir de formulaires au lieu de champs, ou importer un modèle à partir de formulaires au lieu de modèles. Un exemple: from recurrence.forms import RecurrenceFieldmais ça aurait dû l'être from recurrence.fields import RecurrenceField.
hlongmore
Encore une raison. Assurez-vous que le modèle est utilisé dans une route pour le site Web (via admin ou autre). "Le makemigrationsscript recherche les modèles qui sont connectés à partir de urls.py". Trouvé ici stackoverflow.com/questions/43093651/…
Kyle
exemple cmd:python manage.py makemigrations -v 3 <app_name>
Charlie 木匠
Lorsque j'ajoute une table, puis que j'ajoute une clé étrangère, référence cette nouvelle table en même temps. Il doit être divisé en 2 étapes: étape préalable: ajoutez INSTALLED_APPS aux paramètres. 1) créer une nouvelle table: python manage.py makemigrations <app_name>; 2) ajouter une clé étrangère: python manage.py makemigrations
Charlie 木匠
26

J'ai lu de nombreuses réponses à cette question indiquant souvent de simplement exécuter makemigrationsd'autres manières. Mais pour moi, le problème était dans la Metasous - classe des modèles.

J'ai une configuration d'application qui dit label = <app name>(dans le apps.pyfichier, à côté models.py, views.pyetc.). Si, par hasard, votre méta-classe n'a pas le même libellé que le libellé de l'application (par exemple, parce que vous divisez une trop grande application en plusieurs), aucun changement n'est détecté (et aucun message d'erreur utile). Donc, dans ma classe de modèle, j'ai maintenant:

class ModelClassName(models.Model):

    class Meta:
        app_label = '<app name>' # <-- this label was wrong before.

    field_name = models.FloatField()
    ...

Lancer Django 1.10 ici.

onekiloparsec
la source
13

C'est un commentaire mais devrait probablement être une réponse.

Assurez-vous que le nom de votre application est dans settings.py INSTALLED_APPSsinon quoi que vous fassiez, les migrations ne seront pas exécutées.

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    'blog',
]

Puis exécutez:

./manage.py makemigrations blog
Stephen
la source
mais il crée le nom de la table comme 'appname_modelname', lorsque nous exécutons la commande 'manage.py migrate'
Daniyal Javaid
Voir les méta-options du modèle pour changer le nom de la table
stephen
11

J'ai eu un autre problème non décrit ici, qui m'a rendu fou.

class MyModel(models.Model):
    name = models.CharField(max_length=64, null=True)  # works
    language_code = models.CharField(max_length=2, default='en')  # works
    is_dumb = models.BooleanField(default=False),  # doesn't work

J'avais un ',' à la fin peut-être sur une ligne à partir du copier-coller. La ligne avec is_dumb ne crée pas de migration de modèle avec './manage.py makemigrations' mais ne génère pas non plus d'erreur. Après avoir supprimé le ',' cela a fonctionné comme prévu.

Soyez donc prudent lorsque vous copiez et collez :-)

yvess
la source
La virgule de fin peut également causer des bogues ailleurs; la virgule fait de l'instruction un tuple, donc is_dumbest égal à (models.BooleanField(default=False), )qui makemigrationsne sait pas comment convertir en une colonne de base de données.
hlongmore
8

Il y a parfois quand ./manage.py makemigrationsest supérieur à ./manage.py makemigrations <myapp>parce qu'il peut gérer certains conflits entre les applications.

Ces occasions se produisent en silence et il faut plusieurs heures swearingpour comprendre la vraie signification du No changes detectedmessage redouté .

Par conséquent, il est préférable d'utiliser la commande suivante:

./manage.py makemigrations <myapp1> <myapp2> ... <myappN>

raratiru
la source
7

J'avais copié une table depuis l'extérieur de django et la classe Meta était par défaut "managed = false". Par exemple:

class Rssemailsubscription(models.Model):
    id = models.CharField(primary_key=True, max_length=36)
    ...
    area = models.FloatField('Area (Sq. KM)', null=True)

    class Meta:
        managed = False
        db_table = 'RSSEmailSubscription'

En changeant manged en True, makemigrations a commencé à prendre en compte les changements.

Dan Cogswell
la source
4
  1. Assurez-vous que votre application est mentionnée dans installed_apps dans settings.py
  2. Assurez-vous que votre classe de modèle étend les modèles.
Amandeep Singh
la source
2

J'ai résolu ce problème en faisant ceci:

  1. Effacez le fichier "db.sqlite3". Le problème ici est que votre base de données actuelle sera effacée, vous devrez donc la refaire.
  2. Dans le dossier migrations de votre application modifiée, effacez le dernier fichier mis à jour. N'oubliez pas que le premier fichier créé est: "0001_initial.py". Par exemple: j'ai créé une nouvelle classe et l'enregistre par la procédure "makemigrations" et "migrate", maintenant un nouveau fichier appelé "0002_auto_etc.py" a été créé; efface le.
  3. Allez dans le dossier " pycache " (dans le dossier migrations) et effacez le fichier "0002_auto_etc.pyc".
  4. Enfin, allez dans la console et utilisez "python manage.py makemigrations" et "python manage.py migrate".
Juan David Argüello Plata
la source
2

J'ai oublié de mettre les bons arguments:

class LineInOffice(models.Model):   # here
    addressOfOffice = models.CharField("Корхоная жош",max_length= 200)   #and here
    ...

dans models.py, puis il a commencé à laisser tomber cet ennuyeux

Aucune modification détectée dans l'application «myApp»

CodeToLife
la source
2

Une autre raison possible est si vous aviez des modèles définis dans un autre fichier (pas dans un package) et que vous ne les avez référencés nulle part ailleurs.

Pour moi, le simple fait d'ajouter from .graph_model import *à admin.py(où graph_model.pyétait le nouveau fichier) a résolu le problème.

Nick Lothian
la source
2

Mon problème était beaucoup plus simple que les réponses ci-dessus et probablement une raison beaucoup plus courante tant que votre projet est déjà configuré et fonctionne. Dans l'une de mes applications qui fonctionnait depuis longtemps, les migrations semblaient bancales, alors pressé, j'ai fait ce qui suit:

rm -r */migrations/*
rm db.sqlite3
python3 manage.py makemigrations
No changes detected

Whaat ??

J'avais également supprimé par erreur tous les __init__.pyfichiers :( - Tout fonctionnait à nouveau après mon entrée et:

touch ads1/migrations/__init__.py

Pour chacune de mes applications, le a makemigrationsfonctionné à nouveau.

Il s'avère que j'avais créé manuellement une nouvelle application en copiant une autre et que j'avais oublié de mettre le __init__.pydans le migrationsdossier et cela m'a confié que tout était bancal - ce qui m'a amené à aggraver les choses avec un rm -rcomme décrit ci-dessus.

J'espère que cela aidera quelqu'un à insulter l'erreur "Aucun changement détecté" pendant quelques heures.

drchuck
la source
1

La solution est que vous devez inclure votre application dans INSTALLED_APPS.

Je l'ai manqué et j'ai trouvé le même problème.

après avoir spécifié le nom de mon application, la migration a réussi

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'boards',
]

veuillez noter que j'ai mentionné les tableaux en dernier, qui est le nom de mon application.

sradha
la source
1

INSTALLED_APPS = [

'blog.apps.BlogConfig',
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',

]

assurez-vous que 'blog.apps.BlogConfig', (ceci est inclus dans votre settings.py afin de faire les migrations de votre application)

puis exécutez python3 manage.py blog makemigrations ou le nom de votre application

Piyush Chandra
la source
1

Un problème très stupide que vous pouvez également avoir est d'en définir deux class Metadans votre modèle. Dans ce cas, toute modification apportée au premier ne sera pas appliquée lors de l'exécution makemigrations.

class Product(models.Model):
    somefield = models.CharField(max_length=255)
    someotherfield = models.CharField(max_length=255)

    class Meta:
        indexes = [models.Index(fields=["somefield"], name="somefield_idx")]

    def somefunc(self):
        pass

    # Many lines...

    class Meta:
        indexes = [models.Index(fields=["someotherfield"], name="someotherfield_idx")]
nbeuchat
la source
1

Je sais que c'est une vieille question, mais je me suis battu avec ce même problème toute la journée et ma solution était simple.

J'avais ma structure de répertoire quelque chose du genre ...

apps/
   app/
      __init__.py
      app_sub1/
           __init__.py
           models.py
      app_sub2/
           __init__.py
           models.py
      app_sub3/
           __init__.py
           models.py
   app2/
      __init__.py
      app2_sub1/
           __init__.py
           models.py
      app2_sub2/
           __init__.py
           models.py
      app2_sub3/
           __init__.py
           models.py
    main_app/
      __init__.py
      models.py

Et comme tous les autres modèles jusqu'à celui avec main_applequel j'ai eu un problème étaient importés ailleurs qui ont fini par être importés à partir de laquelle était enregistré dans le INSTALLED_APPS, j'ai juste eu de la chance qu'ils aient tous fonctionné.

Mais comme je n'ai ajouté que chacun appà INSTALLED_APPSet non le app_sub*quand j'ai finalement ajouté un nouveau fichier de modèles qui n'a été importé nulle part ailleurs, Django l'a totalement ignoré.

Ma solution consistait à ajouter un models.pyfichier au répertoire de base de chacun appcomme ceci ...

apps/
   app/
      __init__.py
      models.py <<<<<<<<<<--------------------------
      app_sub1/
           __init__.py
           models.py
      app_sub2/
           __init__.py
           models.py
      app_sub3/
           __init__.py
           models.py
   app2/
      __init__.py
      models.py <<<<<<<<<<--------------------------
      app2_sub1/
           __init__.py
           models.py
      app2_sub2/
           __init__.py
           models.py
      app2_sub3/
           __init__.py
           models.py
    main_app/
      __init__.py
      models.py

puis ajoutez from apps.app.app_sub1 import *et ainsi de suite à chacun des fichiers de appniveau models.py.

Bleh ... cela m'a pris tellement de temps à comprendre et je n'ai trouvé la solution nulle part ... Je suis même allé à la page 2 des résultats Google.

J'espère que cela aide quelqu'un!

Tim
la source
1

J'ai eu un problème similaire avec django 3.0, selon la section migrations de la documentation officielle , l'exécuter était suffisant pour mettre à jour la structure de ma table:

python manage.py makemigrations
python manage.py migrate

Mais le résultat était toujours le même: «aucun changement détecté» sur mes modèles après avoir exécuté le script «makemigrations». J'ai eu une erreur de syntaxe sur models.py au niveau du modèle que je voulais mettre à jour sur db:

field_model : models.CharField(max_length=255, ...)

au lieu de:

field_model = models.CharField(max_length=255, ...)

Résoudre cette erreur stupide, avec ces commandes, la migration s'est faite sans problème. Peut-être que cela aide quelqu'un.

Yair Abad
la source
0

Vous devez ajouter polls.apps.PollsConfigà INSTALLED_APPSensetting.py

Minou
la source
0

Dans mon cas, j'ai oublié d'insérer les arguments de classe

Faux:

class AccountInformation():

Correct

class AccountInformation(models.Model):
Jonas
la source
0

Dans mon cas, j'ai d'abord ajouté un champ au modèle et Django a dit qu'il n'y avait aucun changement.

Alors j'ai décidé de changer le "nom de table" du modèle, makemigrations a fonctionné. Ensuite, j'ai changé le nom de la table par défaut, et le nouveau champ était également là.

Il y a un "bogue" dans le système de migration django, parfois il ne voit pas le nouveau champ. Peut être lié au champ de date.

tolga
la source
0

La raison possible pourrait être la suppression du fichier db existant et du dossier de migrations que vous pouvez utiliser python, manage.py makemigrations <app_name>cela devrait fonctionner. J'ai déjà été confronté à un problème similaire.

Akash G Krishnan
la source
0

Encore un cas de bord et une solution:

J'ai ajouté un champ booléen, et en même temps ajouté un @property le référençant, avec le même nom (doh). Commenté la propriété et la migration voit et ajoute le nouveau champ. Renommé la propriété et tout va bien.

kgeo
la source
0

Si vous disposez du managed = Truemodèle Meta in yout, vous devez le supprimer et effectuer une migration. Ensuite, exécutez à nouveau les migrations, il détectera les nouvelles mises à jour.

Irshu
la source
0

Lors de l'ajout de nouveaux modèles à l'application django api et de l'exécution de python manage.py makemigrationsl'outil, aucun nouveau modèle n'a été détecté.

Ce qui est étrange, c'est que les anciens modèles ont été sélectionnés makemigrations, mais c'est parce qu'ils étaient référencés dans la urlpatternschaîne et que l'outil les a détectés d'une manière ou d'une autre. Alors gardez un œil sur ce comportement.

Le problème était dû au fait que la structure de répertoires correspondant au package models contenait des sous-packages et que tous les __init__.pyfichiers étaient vides. Ils doivent importer explicitement toutes les classes requises dans chaque sous-dossier et dans les modèles __init__.py pour que Django les récupère avec l' makemigrationsoutil.

models
  ├── __init__.py          <--- empty
  ├── patient
     ├── __init__.py      <--- empty
     ├── breed.py
     └── ...
  ├── timeline
     ├── __init__.py      <-- empty
     ├── event.py
     └── ...
atoledo
la source
0

Essayez d'enregistrer votre modèle dans admin.py, voici un exemple: - admin.site.register (YourModelHere)

Vous pouvez faire les choses suivantes: - 1. admin.site.register (YourModelHere) # Dans admin.py 2. Rechargez la page et réessayez 3. Appuyez sur CTRL-S et enregistrez 4. Il peut y avoir une erreur, vérifiez spécialement les modèles .py et admin.py 5. Ou, à la fin de tout cela, redémarrez simplement le serveur

GURU RAJ
la source
0

J'espère que cela pourrait aider quelqu'un d'autre, car j'ai fini par passer des heures à essayer de le chasser.

Si vous avez une fonction dans votre modèle du même nom, cela supprimera la valeur. Assez évident avec le recul, mais néanmoins.

Donc, si vous avez quelque chose comme ça:

class Foobar(models.Model):
    [...]
    something = models.BooleanField(default=False)

    [...]
    def something(self):
        return [some logic]

Dans ce cas, la fonction remplacera le paramètre ci-dessus, le rendant "invisible" pour makemigrations.

vpetersson
la source
0

La meilleure chose que vous puissiez faire est de supprimer la base de données existante. Dans mon cas, j'utilisais la base de données SQL phpMyAdmin, donc je supprime manuellement la base de données créée ici.

Après la suppression: Je crée une base de données dans PhpMyAdmin et n'ajoute aucune table.

Exécutez à nouveau les commandes suivantes:

python manage.py makemigrations

python manage.py migrate

Après ces commandes : Vous pouvez voir que django a automatiquement créé d'autres tables nécessaires dans la base de données (il y a environ 10 tables).

python manage.py makemigrations <app_name>

python manage.py migrate

Et enfin: après les commandes ci-dessus, tous les modèles (tables) que vous avez créés sont directement importés dans la base de données.

J'espère que cela aidera.

HITESH GUPTA
la source
0

Mon problème avec cette erreur, c'est que j'avais inclus:

class Meta:
   abstract = True

Modèle intérieur pour lequel je voulais créer une migration.

Dolidod Teethtard
la source
0

J'ai eu un problème différent lors de la création d'une nouvelle application appelée deals. Je voulais séparer les modèles à l'intérieur de cette application, donc j'avais 2 fichiers de modèle nommés deals.pyet dealers.py. En courant, python manage.py makemigrationsj'ai:No changes detected .

Je suis allé de l'avant et à l'intérieur du __init__.pyqui vit sur le même répertoire où vivaient mes fichiers de modèle (offres et revendeur) que j'ai fait

from .deals import *
from .dealers import *

Et puis le makemigrations commande a fonctionné.

Il s'avère que si vous n'importez les modèles nulle part OU que le nom de votre fichier de modèles ne l'est pas, models.pyles modèles ne seront pas détectés.

Un autre problème qui m'est arrivé est la façon dont j'ai écrit l'application dans settings.py:

J'ai eu:

apps.deals

Cela aurait dû inclure le dossier du projet racine:

cars.apps.deals
elad argent
la source