Django - Makemigrationen - Keine Änderungen festgestellt

Ich habe versucht, Migrationen innerhalb einer vorhandenen App mit dem Befehl makemigrations zu erstellen, aber es wird "Keine Änderungen erkannt" ausgegeben.

Normalerweise erstelle ich mit dem startappBefehl neue Apps, habe sie jedoch beim Erstellen nicht für diese App verwendet.

Nach dem Debuggen stellte ich fest, dass keine Migration erstellt wird, da die migrations Paket / der Ordner in einer App fehlt.

Wäre es besser, wenn der Ordner erstellt wird, wenn er nicht vorhanden ist, oder wenn mir etwas fehlt?

Führen Sie makemigrationsden App-Namen aus und geben Sie ihn an, um erste Migrationen für eine App zu erstellen . Der Migrationsordner wird erstellt.

./manage.py makemigrations <myapp>

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

Mein Problem (und damit die Lösung) war noch anders als die oben beschriebenen.

Ich habe keine models.pyDatei verwendet, sondern ein modelsVerzeichnis erstellt und die my_model.pyDatei dort erstellt, in der ich mein Modell abgelegt habe. Django konnte mein Modell nicht finden und schrieb, dass keine Migrationen angewendet werden müssen.

Meine Lösung war: In der my_app/models/__init__.pyDatei habe ich diese Zeile hinzugefügt: from .my_model import MyModel

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

1. Migrationsordner Sie benötigen ein Migrationspaket in Ihrer App.
2. INSTALLED_APPS Sie müssen Ihre App im INSTALLED_APPS.dict angeben
3. Ausführlichkeit beginnt damit, makemigrations -v 3nach Ausführlichkeit zu suchen . Dies könnte etwas Licht in das Problem bringen.
4. Vollständiger Pfad In INSTALLED_APPSwird empfohlen , die vollständige Modul app Config - Pfad ‚apply.apps.MyAppConfig‘ angeben
5. --Einstellungen Sie möchten möglicherweise sicherstellen, dass die richtige Einstellungsdatei festgelegt ist:manage.py makemigrations --settings mysite.settings
6. App-Namen angeben explizit an. Geben Sie den App-Namen ein. manage.py makemigrations myappDadurch werden die Migrationen nur für die App eingegrenzt und Sie können das Problem eingrenzen.

7. Modell Meta Check Sie haben das Recht app_labelin Ihrem Modell-Meta

8. Debug django Debug - django Kern - Skript. Das Makemigrations-Kommando ist ziemlich einfach.So geht's im Pycharm . ändern Ihre Skriptdefinition entsprechend (zB: makemigrations --traceback myapp)

Mehrere Datenbanken:

• DB-Router Wenn Sie mit einem Django-DB-Router arbeiten, muss die Router-Klasse (Ihre benutzerdefinierte Router-Klasse) die allow_syncdbMethode implementieren .

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

Ich habe viele Antworten auf diese Frage gelesen und oft gesagt, dass ich einfach makemigrationsauf andere Weise laufen soll . Aber für mich lag das Problem in der MetaUnterklasse der Modelle.

Ich habe eine app Config , das sagt label = <app name>(in der apps.pyDatei, neben models.py, views.pyusw.). Wenn Ihre Meta-Klasse zufällig nicht dieselbe Bezeichnung wie die App-Bezeichnung hat (z. B. weil Sie eine zu große App in mehrere aufteilen), werden keine Änderungen erkannt (und es gibt keinerlei hilfreiche Fehlermeldung). Also 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.

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

Stellen Sie sicher, dass sich Ihr App-Name in settings.py befindet. INSTALLED_APPSAndernfalls werden die Migrationen unabhängig von Ihrer Tätigkeit 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

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 auch keinen Fehler ausgegeben. Nach dem Entfernen des ',' funktionierte es wie erwartet.

Sei also vorsichtig beim Kopieren und Einfügen :-)

Es gibt manchmal ./manage.py makemigrationsZeiten, in denen es überlegen ist, ./manage.py makemigrations <myapp>weil es bestimmte Konflikte zwischen Apps behandeln kann.

Diese Anlässe treten stillschweigend auf und es dauert mehrere Stunden swearing, um die wahre Bedeutung der gefürchteten No changes detectedNachricht zu verstehen .

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

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

Ich hatte eine Tabelle von außerhalb von Django kopiert und die Meta-Klasse war standardmäßig "verwaltet = falsch". Beispielsweise:

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 den Wechsel von Manged zu True begannen Makemigrationen, Veränderungen zu erfassen.

1. Stellen Sie sicher, dass Ihre App in installierte_Apps in settings.py erwähnt wird
2. Stellen Sie sicher, dass Ihre Modellklasse die Modelle erweitert

Ich habe dieses Problem folgendermaßen gelöst:

1. Löschen Sie die Datei "db.sqlite3". Das Thema hierbei ist, dass Ihre aktuelle Datenbank gelöscht wird, sodass 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" lautet. Beispiel: Ich habe eine neue Klasse erstellt und sie mit der Prozedur "makemigrations" und "migrate" registriert. Jetzt wurde eine neue Datei mit dem Namen "0002_auto_etc.py" erstellt. lösche es.
3. Gehen Sie zum Ordner " pycache " (innerhalb des Migrationsordners) und löschen Sie die Datei "0002_auto_etc.pyc".
4. Gehen Sie zum Schluss zur Konsole und verwenden Sie "python manage.py makemigrations" und "python manage.py migrate".

Ich habe vergessen, die richtigen Argumente anzugeben:

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

in models.py und dann fing es an, das nervig fallen zu lassen

In der App 'myApp' wurden keine Änderungen festgestellt.

Ein weiterer möglicher Grund ist, dass Sie einige Modelle in einer anderen Datei (nicht in einem Paket) definiert haben und nirgendwo anders darauf verwiesen haben.

Für mich wurde das Problem durch einfaches Hinzufügen from .graph_model import *zu admin.py(wo graph_model.pywar die neue Datei) behoben.

Mein Problem war viel einfacher als die obigen Antworten und wahrscheinlich ein weitaus häufigerer Grund, solange Ihr Projekt bereits eingerichtet ist und funktioniert. In einer meiner Anwendungen, die schon lange funktionierte, schienen Migrationen wackelig zu sein. In Eile habe ich Folgendes getan:

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

Was?

Ich hatte fälschlicherweise auch alle __init__.pyDateien entfernt :( - Alles funktionierte wieder, nachdem ich reingegangen war und:

touch ads1/migrations/__init__.py

Für jede meiner Anwendungen hat das makemigrationsdann wieder funktioniert.

Es stellte sich heraus, dass ich eine neue Anwendung manuell erstellt hatte, indem ich eine andere kopierte, und vergessen hatte, sie __init__.pyin den migrationsOrdner zu legen rm -r.

Ich hoffe, dies hilft jemandem, einige Stunden lang nicht auf den Fehler "Keine Änderungen festgestellt" zu schwören.

Die Lösung besteht darin, dass Sie Ihre App in INSTALLED_APPS aufnehmen müssen.

Ich habe es verpasst und das gleiche Problem gefunden.

Nach Angabe meines App-Namens 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 zuletzt Boards erwähnt habe, das ist mein App-Name.

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 den Blog python3 manage.py makemigrations oder Ihren App-Namen aus

Ein sehr dummes Problem, das Sie auch haben können, ist, zwei class Metain Ihrem Modell zu definieren . In diesem Fall wird beim Ausführen keine Änderung an der ersten vorgenommen 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")]

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 zu dem, mit dem ich ein Problem hatte, an einen anderen Ort importiert wurden, der schließlich importiert wurde und von main_appdem im registriert wurdeINSTALLED_APPS , hatte ich einfach Glück, dass sie alle funktionierten.

Aber da ich nur hinzugefügt jede appan INSTALLED_APPSund nicht dieapp_sub* als ich endlich eine neue Modelldatei hinzugefügt habe, die nirgendwo anders importiert wurde, hat Django sie völlig ignoriert.

Mein Fix war das Hinzufügen einer models.pyDatei zum Basisverzeichnis von jedem appwie 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

und dann from apps.app.app_sub1 import *zu jedem appLevel hinzufügen und so weitermodels.py Dateien .

Bleh ... das hat so lange gedauert und ich konnte nirgendwo die Lösung finden ... Ich bin sogar zu Seite 2 der Google-Ergebnisse gegangen.

Hoffe das hilft jemandem!

Sie sollten hinzufügen , polls.apps.PollsConfigum INSTALLED_APPSinsetting.py

In meinem Fall habe ich vergessen, die Klassenargumente einzufügen

Falsch:

class AccountInformation():

Richtig

class AccountInformation(models.Model):

In meinem Fall habe ich dem Modell zuerst ein Feld hinzugefügt, und Django sagte, dass es keine Änderungen gibt.

Als ich mich entschied, den "Tabellennamen" des Modells zu ändern, funktionierten Makemigrationen. Dann habe ich den Tabellennamen wieder auf Standard geändert und das neue Feld war auch da.

Es gibt einen "Fehler" im Django-Migrationssystem, manchmal wird das neue Feld nicht angezeigt. Könnte mit dem Datumsfeld zusammenhängen.

Der mögliche Grund könnte das Löschen der vorhandenen Datenbankdatei und des Migrationsordners sein. Sie können Python verwenden. manage.py makemigrations <app_name>Dies sollte funktionieren. Ich hatte einmal ein ähnliches Problem.

Noch ein Randfall und eine Lösung:

Ich habe ein boolesches Feld hinzugefügt und gleichzeitig eine @ Eigenschaft hinzugefügt, die darauf verweist, mit demselben Namen (doh). Kommentiert die Eigenschaft und Migration sieht und fügt das neue Feld hinzu. Das Anwesen wurde umbenannt und alles ist gut.

Wenn Sie das managed = Truein Ihrem Modell Meta haben, müssen Sie es entfernen und eine Migration durchführen. Führen Sie dann die Migrationen erneut aus, um die neuen Updates zu erkennen.

Beim Hinzufügen neuer Modelle zur Django-API-Anwendung und Ausführen python manage.py makemigrationsdes Tools wurden keine neuen Modelle erkannt .

Das Seltsame war, dass die alten Modelle von ausgewählt wurden makemigrations, aber das lag daran, dass sie in der urlpatternsKette referenziert wurden und das Werkzeug sie irgendwie erkannte. Behalten Sie dieses Verhalten im Auge.

Das Problem war, dass die dem Modellpaket entsprechende Verzeichnisstruktur Unterpakete enthielt und alle __init__.pyDateien leer waren. Sie müssen explizit alle erforderlichen Klassen in jeden Unterordner und in die Modelle importieren, __init__.pydamit Django sie mit dem makemigrationsTool abrufen kann.

models
  ├── __init__.py          <--- empty
  ├── patient
  │   ├── __init__.py      <--- empty
  │   ├── breed.py
  │   └── ...
  ├── timeline
  │   ├── __init__.py      <-- empty
  │   ├── event.py
  │   └── ...

Versuchen Sie, Ihr Modell in admin.py zu registrieren. Hier ein Beispiel: - admin.site.register (YourModelHere)

Sie können Folgendes tun: - 1. admin.site.register (YourModelHere) # In admin.py 2. Laden Sie die Seite neu und versuchen Sie es erneut. 3. Drücken Sie STRG-S und speichern Sie. 4. Möglicherweise liegt ein Fehler vor. Überprüfen Sie insbesondere die Modelle .py und admin.py 5. Oder starten Sie am Ende einfach den Server neu

Ich hatte ein ähnliches Problem mit Django 3.0, laut Migrationsabschnitt in der offiziellen Dokumentation . Das Ausführen dieses Problems reichte aus, um meine Tabellenstruktur zu aktualisieren:

python manage.py makemigrations
python manage.py migrate

Die Ausgabe war jedoch immer dieselbe: "Keine Änderung festgestellt" für meine Modelle, nachdem ich das Skript "Makemigrations" ausgeführt habe. Ich hatte einen Syntaxfehler bei models.py bei dem Modell, das ich auf db aktualisieren wollte:

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

anstatt:

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

Um diesen dummen Fehler zu lösen, wurde die Migration mit diesen Befehlen ohne Probleme durchgeführt. Vielleicht hilft das jemandem.

Dies könnte hoffentlich jemand anderem helfen, da ich Stunden damit verbracht habe, dies zu verfolgen.

Wenn Sie eine Funktion innerhalb haben Ihrem Modell , wird der Wert entfernt. Im Nachhinein ziemlich offensichtlich, aber dennoch.

Also, wenn Sie so etwas haben:

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

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

In diesem Fall überschreibt die Funktion die obige Einstellung und macht sie für "unsichtbar" makemigrations.

Das Beste, was Sie tun können, ist, die vorhandene Datenbank zu löschen. In meinem Fall habe ich die SQL-Datenbank phpMyAdmin verwendet, daher habe ich die erstellte Datenbank manuell gelöscht.

Nach dem Löschen: Ich erstelle eine Datenbank in PhpMyAdmin und füge keine Tabellen hinzu.

Führen Sie erneut die folgenden Befehle aus:

python manage.py makemigrations

python manage.py migrate

Nach diesen Befehlen : Sie können sehen, dass django automatisch andere erforderliche Tabellen in der Datenbank erstellt hat (ca. 10 Tabellen).

python manage.py makemigrations <app_name>

python manage.py migrate

Und zum Schluss: Nach den obigen Befehlen werden alle von Ihnen erstellten Modelle (Tabellen) direkt in die Datenbank importiert.

Hoffe das wird helfen.

Mein Problem mit diesem Fehler war, dass ich Folgendes aufgenommen hatte:

class Meta:
   abstract = True

Innerhalb des Modells, für das ich eine Migration erstellen wollte.

Ich hatte ein anderes Problem beim Erstellen einer neuen App namens deals. Ich wollte die Modelle in dieser App trennen, also hatte ich 2 Modelldateien mit dem Namen deals.pyund dealers.py. Beim Laufen python manage.py makemigrationsbekam ich : No changes detected.

Ich ging voran und in das, __init__.pydas sich in demselben Verzeichnis befindet, in dem sich meine Modelldateien befanden (Angebote und Händler), das ich getan habe

from .deals import *
from .dealers import *

Und dann makemigrationsfunktionierte der Befehl.

Es stellt sich heraus, dass models.pydie Modelle nicht erkannt werden, wenn Sie die Modelle nirgendwo importieren ODER der Dateiname Ihres Modells nicht .

Ein weiteres Problem, das mir passiert ist, ist die Art und Weise, wie ich die App geschrieben habe settings.py:

Ich hatte:

apps.deals

Es sollte den Stammprojektordner enthalten haben:

cars.apps.deals