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
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).
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.
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
Django ne détecte pas le type de migration à exécuter lors de la commande makemigrations
pour plusieurs raisons.
INSTALLED_APPS
.dict.makemigrations -v 3
pour verbosity. Cela pourrait éclairer un peu le problème.INSTALLED_APPS
, il est recommandé de spécifier le chemin de configuration complet de l'application du module 'apply.apps.MyAppConfig'manage.py makemigrations --settings mysite.settings
manage.py makemigrations myapp
- qui réduit les migrations pour l'application seule et vous aide à isoler le problème. model meta vérifie que vous avez le bon app_label
dans votre méta de modèle
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
)
allow_syncdb
.makemigrations crée toujours des migrations pour les modifications de modèle, mais si allow_migrate () renvoie False,
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
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>
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 :-)
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.
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!
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")]
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
J'ai résolu ce problème en faisant ceci:
Vous devriez ajouter polls.apps.PollsConfig
à INSTALLED_APPS
dans setting.py
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.
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.