web-dev-qa-db-fra.com

Django 1.9 - makemigrations - Aucune modification détectée

Avec une application existante, j'essayais de créer des migrations à l'aide de la commande makemigrations mais la mention "Aucune modification détectée".

Habituellement, je crée de nouvelles applications à l'aide de la commande startapp, mais cette application en particulier ne l'était pas.

Après un certain temps de débogage, j'ai constaté qu'il ne créait pas de migration car migrations package/folder est manquant dans une application. 

Sera mieux, il crée un dossier s'il n'est pas là ou peut-être qu'il me manque quelque chose

72
Dilraj

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

./manage.py makemigrations <myapp>

Votre application doit d'abord être incluse dans INSTALLED_APPS (à l'intérieur de settings.py).

141
Alasdair

J'ai lu de nombreuses réponses à cette question, indiquant souvent de lancer simplement makemigrations d'une autre manière. Mais pour moi, le problème se situait dans la sous-classe Meta de modèles.

J'ai une configuration d'application qui dit label = <app name> (dans le fichier apps.py, à côté de models.py, views.py, etc.). Si par hasard votre méta classe n'a pas le même libellé que celui de l'application (par exemple, parce que vous divisez une trop grosse application en plusieurs), aucune modification n'est détectée (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.

22
onekiloparsec

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

Je n'utilisais pas le fichier models.py, mais j'ai créé un répertoire models et créé le fichier my_model.py, où j'ai mis mon modèle. Django n’ayant pas pu trouver mon modèle, il a écrit qu’il n’y avait pas de migration à appliquer. 

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

17

Django ne détecte pas le type de migration à exécuter lors de la commande makemigrations pour plusieurs raisons.

  1. dossier de migration Vous avez besoin d'un package de migration dans votre application.
  2. INSTALLED_APPS Vous devez spécifier votre application dans le INSTALLED_APPS .dict.
  3. Verbosity commence par exécuter makemigrations -v 3 pour verbosity. Cela pourrait éclairer un peu le problème.
  4. Chemin complet Dans INSTALLED_APPS, il est recommandé de spécifier le chemin de configuration complet 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 dans manage.py makemigrations myapp - qui réduit les migrations pour l'application seule et vous aide à isoler le problème. 
  7. model meta vérifie que vous avez le bon app_label dans votre méta de modèle 

  8. Déboguer Django déboguer le script principal Django. La commande makemigrations est assez simple. Voici comment faire dans pycharm . changez votre définition de script en conséquence (ex: makemigrations --traceback myapp)

Plusieurs bases de données:

  • Db Router Lorsque vous utilisez un routeur Django db, la classe de routeur (votre classe de routeur personnalisée) doit implémenter la méthode allow_syncdb.

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

16
user1134422

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

Assurez-vous que le nom de votre application figure dans settings.py INSTALLED_APPS, sinon, 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 lancez:

./manage.py makemigrations blog
10
surfer190

Il arrive parfois que ./manage.py makemigrations soit supérieur à ./manage.py makemigrations <myapp> car il peut gérer certains conflits entre les applications. 

Ces occasions se produisent en silence et il faut plusieurs heures de swearing pour comprendre le sens réel du message redouté No changes detected

Par conséquent, il est préférable de faire appel à la commande suivante:

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

6
raratiru

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'ai eu un "," en queue dans une ligne peut-être de copier-coller. La ligne avec is_dumb ne crée pas de modèle de migration avec './manage.py makemigrations' mais ne génère pas non plus d'erreur. Après avoir retiré le "," cela a fonctionné comme prévu. 

Alors faites attention quand vous copiez et collez :-) 

2
yvess

J'avais copié une table depuis l'extérieur de Django et la classe Meta était définie par défaut sur "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 modifications.

2
Dan Cogswell

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

J'ai eu ma structure de répertoire quelque chose dans le sens de ...

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 lequel j'avais un problème, étaient importés ailleurs et finissaient par importer à partir de main_app qui était enregistré dans le INSTALLED_APPS, j'ai simplement eu de la chance qu'ils fonctionnent tous.

Mais comme je n’ai ajouté que chaque app à INSTALLED_APPS et non le app_sub* quand j’ai finalement ajouté un nouveau fichier de modèles qui n’était pas importé ailleurs, Django l’a totalement ignoré.

Ma solution consistait à ajouter un fichier models.py au répertoire de base de chaque app comme 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 app niveau models.py.

Bleh ... cela m'a pris SO longtemps à comprendre et je ne pouvais trouver la solution nulle part ... Je suis même allé à la page 2 des résultats Google.

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

1
Tim

Un problème très stupide que vous pouvez également avoir est de définir deux class Meta dans votre modèle. Dans ce cas, aucune modification de la première ne sera appliquée lors de l'exécution de 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")]
1
nbeuchat
  1. Assurez-vous que votre application est mentionnée dans installed_apps dans settings.py.
  2. Assurez-vous que la classe de modèle étend les modèles.Modèle
0
Amandeep Singh

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" est inclus dans votre fichier settings.py afin de permettre la migration de vos applications.

puis lancez le blog python3 manage.py makemigrations ou le nom de votre application

0
Piyush Chandra

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

  1. Effacez le fichier "db.sqlite3". Le problème est que votre base de données actuelle sera effacée, vous devrez donc la refaire à nouveau.
  2. Dans le dossier de migration de votre application modifiée, effacez le dernier fichier mis à jour. Rappelez-vous que le premier fichier créé est: "0001_initial.py". Par exemple: J'ai créé une nouvelle classe et l'enregistre par les procédures "makemigrations" et "migrate". Un nouveau fichier appelé "0002_auto_etc.py" a été créé. efface le.
  3. Allez dans le dossier "pycache" (dans le dossier des migrations) et effacez le fichier "0002_auto_etc.pyc".
  4. Enfin, accédez à la console et utilisez "python manage.py makemigrations" et "python manage.py migrate". 

Vous devriez ajouter polls.apps.PollsConfig à INSTALLED_APPS dans setting.py

0
Kitty

Tout d’abord, assurez-vous que votre application est enregistrée dans Installed_app dans le fichier setting.py. La réponse ci-dessus fonctionne parfaitement.

0
Arjjun

La solution consiste à inclure votre application dans INSTALLED_APPS.

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

après avoir spécifié ma migration de nom d'application est devenue réussie

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

s'il vous plaît noter que j'ai mentionné des conseils en dernier, qui est mon nom d'application.

0
sradha