Django - makemigrations - Aucun changement détecté

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?

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).

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

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,

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.

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

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 :-)

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>

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.

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.

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".

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»

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.

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.

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.

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

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")]

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!

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.

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

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

Faux:

class AccountInformation():

Correct

class AccountInformation(models.Model):

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.

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.

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.

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.

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
  │   └── ...

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

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.

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.

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.

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