wake-up-neo.net

Django 1.9 - Makemigrations - Keine Änderungen festgestellt

Mit einer vorhandenen App habe ich versucht, Migrationen mit dem Befehl "makemigrations" zu erstellen, aber es wird "Keine Änderungen erkannt" angezeigt.

Normalerweise erstelle ich neue Apps mit dem Befehl startapp, aber diese spezielle App war es nicht.

Nach einiger Zeit des Debugging stellte ich fest, dass keine Migration erstellt wird, da migrations package/folder in einer App fehlt. 

Besser wäre es, Ordner anzulegen, wenn es nicht da ist oder mir etwas fehlt

72
Dilraj

Um erste Migrationen für eine App zu erstellen, führen Sie makemigrations aus und geben Sie den App-Namen an. Der Migrationsordner wird erstellt.

./manage.py makemigrations <myapp>

Ihre App muss zuerst in INSTALLED_APPS (in settings.py) enthalten sein.

141
Alasdair

Ich habe viele Antworten auf diese Frage gelesen, die oft besagen, makemigrations einfach auf andere Weise auszuführen. Aber für mich lag das Problem in der Meta-Unterklasse von Modellen.

Ich habe eine App-Konfiguration, die label = <app name> sagt (in der apps.py-Datei neben models.py, views.py etc). Wenn Ihre Meta-Klasse möglicherweise nicht das gleiche Label wie das App-Label hat (z. B. weil Sie eine zu große App in mehrere Applets aufteilen), werden keine Änderungen erkannt (und auch keine hilfreiche Fehlermeldung). In meiner Modellklasse habe ich jetzt:

class ModelClassName(models.Model):

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

    field_name = models.FloatField()
    ...

Hier läuft Django 1.10.

22
onekiloparsec

Mein Problem (und damit die Lösung) unterschied sich noch von den oben beschriebenen. 

Ich habe keine models.py-Datei verwendet, sondern ein models-Verzeichnis erstellt und dort die my_model.py-Datei erstellt, in die ich mein Modell gestellt habe. Django konnte mein Modell nicht finden, so dass es keine Migrationen gibt, die angewendet werden können. 

Meine Lösung war: In der my_app/models/__init__.py-Datei habe ich folgende Zeile hinzugefügt: from .my_model import MyModel

Es gibt mehrere mögliche Gründe dafür, dass Django während des makemigrations-Befehls nicht erkennt, was migriert werden soll.

  1. migrationsordner Sie benötigen ein Migrationspaket in Ihrer App.
  2. INSTALLED_APPS Sie müssen Ihre App in INSTALLED_APPS .dict angeben
  3. Verbosity Beginnen Sie mit der Ausführung von makemigrations -v 3 für die Ausführlichkeit. Dies könnte ein wenig Licht auf das Problem werfen.
  4. Vollständiger Pfad In INSTALLED_APPS wird empfohlen, den vollständigen Konfigurationspfad für die Modulanwendung 'apply.apps.MyAppConfig' anzugeben.
  5. --settings Sie möchten möglicherweise sicherstellen, dass die richtige Einstellungsdatei festgelegt ist: manage.py makemigrations --settings mysite.settings 
  6. Namen der App angeben setzt den App-Namen explizit in manage.py makemigrations myapp - Dadurch werden die Migrationen für die App allein eingegrenzt und Sie können das Problem isolieren. 
  7. model meta Überprüfen Sie, ob Sie den richtigen app_label in Ihrem Modell-Meta haben 

  8. Debug Django debuggt das Django-Kernskript. Der Befehl makemigrations ist ziemlich einfach. So geht's in pycharm . Ändern Sie Ihre Skriptdefinition entsprechend (Beispiel: makemigrations --traceback myapp)

Mehrere Datenbanken:

  • Db-Router Wenn Sie mit dem Django-Db-Router arbeiten, muss die Routerklasse (Ihre benutzerdefinierte Routerklasse) die allow_syncdb-Methode implementieren.

makemigrations erstellt immer Migrationen für Modelländerungen, aber wenn allow_migrate () gibt False zurück,

16
user1134422

Es ist ein Kommentar, sollte aber wahrscheinlich eine Antwort sein.

Vergewissern Sie sich, dass Ihr App-Name in "settings.py INSTALLED_APPS" angegeben ist. Andernfalls werden die Migrationen unabhängig von Ihrem Vorgang nicht ausgeführt.

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

    'blog',
]

Dann renne:

./manage.py makemigrations blog
10
surfer190

Es gibt Situationen, in denen ./manage.py makemigrations./manage.py makemigrations <myapp> überlegen ist, da bestimmte Konflikte zwischen Apps verarbeitet werden können. 

Diese Ereignisse treten im Hintergrund auf, und es dauert mehrere Stunden von swearing, um die wahre Bedeutung der gefürchteten No changes detected-Nachricht zu verstehen. 

Daher ist es eine weitaus bessere Wahl, den folgenden Befehl zu verwenden:

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

6
raratiru

Ich hatte ein anderes Problem, das hier nicht beschrieben wurde, was mich verrückt machte.

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

Ich hatte ein abschließendes ',' in einer Zeile, vielleicht von copy & paste. Die Zeile mit is_dumb hat keine Modellmigration mit './manage.py makemigrations' erstellt, aber es wurde auch kein Fehler ausgegeben. Nach dem Entfernen des ',' funktionierte es wie erwartet. 

Seien Sie also vorsichtig beim Kopieren & Einfügen :-) 

2
yvess

Ich hatte eine Tabelle von außerhalb von Django kopiert und die Meta-Klasse war standardmäßig "managed = false". Zum Beispiel:

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'

Durch die Änderung von "Manged" in "True" haben die Makemigrations begonnen, die Änderungen zu übernehmen.

2
Dan Cogswell

Ich weiß, dass dies eine alte Frage ist, aber ich habe den ganzen Tag mit demselben Problem gekämpft und meine Lösung war einfach.

Ich hatte meine Verzeichnisstruktur etwas in der Art von ...

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

Und da alle anderen Modelle bis auf das Modell, mit dem ich ein Problem hatte, an einer anderen Stelle importiert wurden, die schließlich von main_app importierte, der im INSTALLED_APPS registriert war, hatte ich nur das Glück, dass sie alle funktionierten.

Da ich jedoch nur jeden app zu INSTALLED_APPS hinzugefügt habe und nicht den app_sub*, als ich schließlich eine neue Modelldatei hinzufügte, die NIEMALS sonst importiert wurde, ignorierte Django sie vollständig.

Mein Fix war das Hinzufügen einer models.py-Datei zum Basisverzeichnis jedes app wie folgt ...

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

fügen Sie dann from apps.app.app_sub1 import * usw. zu jeder der app-Dateien mit models.py hinzu.

Bleh ... das hat mich SO lange gekostet und ich konnte nirgendwo eine Lösung finden ... Ich ging sogar zu Seite 2 der Google-Ergebnisse.

Hoffe das hilft jemandem!

1
Tim

Ein sehr dummes Problem, das Sie auch haben können, besteht darin, zwei class Meta in Ihrem Modell zu definieren. In diesem Fall wird keine Änderung an der ersten vorgenommen, wenn makemigrations ausgeführt wird.

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. Stellen Sie sicher, dass Ihre App in der Datei "settings.py" unter "installed_apps" aufgeführt ist
  2. Stellen Sie sicher, dass Ihre Modellklasse models.Model erweitert
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',

]

stellen Sie sicher, dass "blog.apps.BlogConfig" (dies ist in Ihrer settings.py enthalten, um Ihre App-Migrationen durchzuführen)

führen Sie dann das Blog python3 manage.py makemigrations oder Ihren App-Namen aus

0
Piyush Chandra

Ich habe dieses Problem dadurch gelöst:

  1. Löschen Sie die Datei "db.sqlite3". Das Problem Hier ist, dass Ihre aktuelle Datenbank gelöscht wird, so dass Sie sie erneut erstellen müssen.
  2. Löschen Sie im Migrationsordner Ihrer bearbeiteten App die zuletzt aktualisierte Datei. Denken Sie daran, dass die erste erstellte Datei "0001_initial.py" ist. Zum Beispiel: Ich habe eine neue Klasse erstellt und sie mit der Prozedur "makemigrations" und "migrate" registriert. Nun wurde eine neue Datei mit dem Namen "0002_auto_etc.py" erstellt. lösche es.
  3. Gehen Sie zum Ordner "pycache" (im Migrationsordner) und löschen Sie die Datei "0002_auto_etc.pyc".
  4. Gehen Sie schließlich zur Konsole und verwenden Sie "python manage.py makemigrations" und "python manage.py migrate". 

Sie sollten polls.apps.PollsConfig zu INSTALLED_APPS in setting.py hinzufügen

0
Kitty

Stellen Sie zunächst sicher, dass Ihre App in der Installed_app in der setting.py registriert ist. Dann funktioniert die obige Antwort einwandfrei

0
Arjjun

Die Lösung ist, dass Sie Ihre App in INSTALLED_APPS einfügen müssen.

Ich habe es vermisst und habe das gleiche Problem gefunden.

nach dem Festlegen meines Anwendungsnamens wurde die Migration erfolgreich

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

bitte beachte, dass ich Boards zuletzt erwähnt habe, was mein App-Name ist.

0
sradha