Django 1.7 - Makemigrationen, die keine Änderungen erkennen

Wenn Sie von einer in Django 1.6 erstellten vorhandenen Anwendung wechseln, müssen Sie (wie ich festgestellt habe) einen Vorschritt ausführen, der in der Dokumentation aufgeführt ist:

python manage.py makemigrations your_app_label

Aus der Dokumentation ist nicht ersichtlich, dass Sie dem Befehl das App-Label hinzufügen müssen. Als Erstes wird python manage.py makemigrations angegeben, was fehlschlagen wird. Die anfängliche Migration wird durchgeführt, wenn Sie Ihre App in Version 1.7 erstellen. Wenn Sie jedoch aus 1.6 kamen, wurde sie nicht ausgeführt. Weitere Informationen finden Sie in der Dokumentation unter 'Hinzufügen von Migration zu Apps' .

Dies kann aus folgenden Gründen passieren:

1. Sie haben die App nicht in der Liste INSTALLED_APPS in settings.py Hinzugefügt. (Sie müssen entweder den app-Namen oder den gepunkteten Pfad zur Unterklasse von AppConfig in apps.py im Verzeichnis hinzufügen App-Ordner (abhängig von der verwendeten Django-Version). Siehe Dokumentation: INSTALLED_APPS
2. Sie haben keinen migrations Ordner in diesen Apps. (Lösung: Erstellen Sie einfach diesen Ordner).
3. Sie haben keine __init__.py -Datei im migrations -Ordner dieser Apps. (Lösung: Erstellen Sie einfach eine leere Datei mit dem Namen __init__.py)
4. Sie haben keine __init__.py -Datei im App-Ordner. (Lösung: Erstellen Sie einfach eine leere Datei mit dem Namen __init__.py)
5. Sie haben keine models.py -Datei in der App
6. Ihre Python-Klasse (die vermutlich ein Modell ist) in models.py erbt nicht Django.db.models.Model
7. Sie haben einen semantischen Fehler bei der Definition von Modellen in models.py.

Hinweis: Ein häufiger Fehler ist das Hinzufügen des migrations-Ordners in der .gitignore-Datei. Beim Klonen von einem Remote-Repo werden der migrations-Ordner und/oder __init__.py-Dateien im lokalen Repo fehlen. Dies verursacht ein Problem.

Ich schlage vor, Migrationsdateien zu ignorieren, indem Sie die folgenden Zeilen in die .gitignore-Datei einfügen

*/migrations/*
!*/migrations/__init__.py

Meine Lösung wurde hier nicht behandelt, deshalb poste ich sie. Ich hatte syncdb für ein Projekt verwendet, nur um es zum Laufen zu bringen. Als ich dann anfing, Django-Migrationen zu verwenden, fälschte es sie zuerst. Dann sagte sie, es sei "OK", aber in der Datenbank passierte nichts.

Meine Lösung bestand darin, einfach alle Migrationsdateien für meine App zu löschen, sowie sowie die Datenbankdatensätze für die App-Migrationen in der Tabelle Django_migrations.

Dann habe ich gerade eine erste Migration mit gemacht:

./manage.py makemigrations my_app

gefolgt von:

./manage.py migrate my_app

Jetzt kann ich problemlos migrieren.

Stimmen Sie @furins zu. Wenn alles in Ordnung zu sein scheint und dennoch dieses Problem auftritt, überprüfen Sie, ob es eine Eigenschaftsmethode mit demselben Titel wie das Attribut gibt, das Sie in der Klasse Model hinzufügen möchten. 

1. Entfernen Sie eine Methode mit einem ähnlichen Namen als Attribut, das Sie hinzufügen.
2. manage.py macht meine Auswahlen my_app
3. manage.py migriert my_app
4. Fügen Sie die Methoden zurück.

Dies ist eine Art dummer Fehler, aber wenn Sie ein zusätzliches Komma am Ende der Felddeklarationszeile in der Modellklasse haben, hat die Zeile keine Wirkung.

Es passiert beim Kopieren und Einfügen des Def. aus der Migration, die selbst als Array definiert ist.

Vielleicht würde dies jemandem helfen :-)

Vielleicht bin ich zu spät, aber haben Sie versucht, einen migrations-Ordner mit einer __init__.py-Datei in Ihrer App zu haben? 

Folgendes hat für mich gearbeitet:

1. Fügen Sie den App-Namen zu settings.py hinzu
2. benutze 'python manage.py makemigrations'
3. benutze 'python manage.py migrate'

Für mich gearbeitet: Python 3.4, Django 1.10

Die Antwort ist auf diesem Stackoverflow-Beitrag von cdvv7788 Migrations in Django 1.7

Wenn Sie diese App zum ersten Mal migrieren, müssen Sie Folgendes verwenden:

manage.py makemigrations myappname Wenn Sie das getan haben, können Sie Folgendes tun:

manage.py migrate Wenn sich Ihre App in der Datenbank befunden hat, ändern Sie ihr Modell und es ist nicht die Aktualisierung der Änderungen an Makemigrations, die Sie wahrscheinlich nicht haben migrierte es noch. Ändern Sie Ihr Modell wieder in seine ursprüngliche Form und führen Sie die .__ aus. erster Befehl (mit dem App-Namen) und migrieren ... es wird gefälscht. Einmal Wenn Sie dies tun, setzen Sie die Änderungen an Ihrem Modell zurück, führen Sie Makemigrations und .__ aus. wieder migrieren und es sollte funktionieren.

Ich hatte genau die gleichen Schwierigkeiten und es funktionierte perfekt.

Ich hatte meine Django-App auf cloud9 verschoben und aus irgendeinem Grund habe ich die erste Migration nie erlebt.

Leute wie ich, die keine Migration mögen, können die folgenden Schritte ausführen.

1. Entfernen Sie die Änderungen, die Sie synchronisieren möchten.
2. Führen Sie python manage.py makemigrations app_label für die erste Migration aus.
3. Führen Sie python manage.py migrate zum Erstellen von Tabellen aus, bevor Sie Änderungen vornehmen.
4. Fügen Sie die Änderungen ein, die Sie im ersten Schritt entfernen.
5. Führen Sie die Schritte 2 und 3 aus.

Wenn Sie einen dieser Schritte verwechselt haben, lesen Sie die Migrationsdateien. Ändern Sie sie, um Ihr Schema zu korrigieren oder unerwünschte Dateien zu entfernen. Vergessen Sie jedoch nicht, den Abhängigkeitsteil der nächsten Migrationsdatei zu ändern.

Ich hoffe, dass dies in Zukunft jemandem helfen wird.

Vielleicht hilft das jemandem. Ich habe eine verschachtelte App verwendet. project.appname und ich hatte tatsächlich projekt und project.appname in INSTALLED_APPS. Durch das Entfernen des Projekts aus INSTALLED_APPS konnten die Änderungen erkannt werden.

Sie möchten den settings.py in der Liste INSTALLED_APPS überprüfen und sicherstellen, dass alle Apps mit Modellen dort aufgelistet sind.

Wenn Sie makemigrations im Projektordner ausführen, werden alle Tabellen aktualisiert, die sich auf alle Apps beziehen, die in settings.py für das Projekt enthalten sind. Nach dem Einfügen wird makemigrations die App automatisch einschließen (dies spart eine Menge Arbeit, so dass Sie makemigrations app_name nicht für jede App in Ihrem Projekt/Ihrer Site ausführen müssen).

Nur für den Fall, dass Sie ein bestimmtes Feld haben, das nicht von Makemigrations identifiziert wird: Überprüfen Sie zweimal, ob Sie eine Eigenschaft mit demselben Namen haben.

beispiel:

field = Django.db.models.CharField(max_length=10, default = '', blank=True, null=True)

# ... later

@property
def field(self):
    pass

die Eigenschaft "überschreibt" die Felddefinition, sodass Änderungen nicht durch makemigrations identifiziert werden.

Hinzufügen dieser Antwort, weil nur diese Methode mir geholfen hat.

Ich habe den Ordnermigrationsgelöscht, in dem makemigrations und migrate ausgeführt wurden.
Es sagte immer noch: Keine Migrationen zu beantragen.

Ich ging in den Ordnermigrateund öffnete die zuletzt erstellte Datei.
kommentiere die gewünschte Migration (sie wurde erkannt und dort eingegeben)
und führen Sie migrate erneut aus.

Dadurch wird die Migrationsdatei im Wesentlichen manuell bearbeitet.
Tun Sie dies nur, wenn Sie den Inhalt der Datei verstehen.

Stellen Sie sicher, dass Ihr Modell nicht abstract ist. Ich habe diesen Fehler gemacht und es hat eine Weile gedauert, also dachte ich, ich würde ihn posten.

Haben Sie nach dem Umbenennen des alten Migrationsordners schemamigration my_app --initial verwendet? Versuch es. Könnte funktionieren. Wenn nicht - versuchen Sie, die Datenbank neu zu erstellen, und führen Sie syncdb + aus. Es hat für mich funktioniert ...

Vielleicht kann das jemandem helfen, ich hatte das gleiche Problem.

Ich habe bereits zwei Tabellen mit der Serialisiererklasse und den Ansichten erstellt. Wenn ich also ein Update durchführen wollte, hatte ich diesen Fehler.

Ich bin diesen Schritten gefolgt:

1. Ich habe .\manage.py makemigrations app gemacht
2. Ich habe .\manage.py migrate ausgeführt
3. Ich habe beide Tabellen meines models.py gelöscht.
4. Ich habe alle Verweise auf meine Tabellen von der Serialisierungs- und Ansichtsklasse gelöscht.
5. Ich habe die Schritte 1 und 2 ausgeführt.
6. Ich habe meine Änderungen nur im models.py abgerufen.
7. Ich führte erneut den Schritt 5 aus.
8. Ich habe alle meine Änderungen wiederhergestellt.

Wenn Sie mit Pycharm arbeiten, ist die Ortsgeschichte sehr hilfreich.

Ich hatte das gleiche Problem, dass ich zweimal Makemigrationen ausführen musste und allerlei seltsames Verhalten. Es stellte sich heraus, dass der Grund des Problems darin bestand, dass ich eine Funktion zum Festlegen von Standarddaten in meinen Modellen verwendete, sodass Migrationen bei jeder Ausführung von Makemigrationen eine Änderung feststellten. Die Antwort auf diese Frage brachte mich auf den richtigen Weg: Vermeiden Sie Makemigrationen, um das Datumsfeld neu zu erstellen

Ich habe kürzlich Django von 1.6 auf 1.8 aktualisiert und hatte nur wenige Apps und Migrationen für sie. Ich habe South und schemamigrations verwendet, um Migrationen in Django 1.6 zu erstellen, die in Django 1.8 fallen gelassen werden. 

Wenn ich nach dem Upgrade neue Modelle hinzufügte, wurden mit dem Befehl makemigrations keine Änderungen festgestellt. Und dann habe ich die von @drojf (1. Antwort) vorgeschlagene Lösung ausprobiert, es hat gut funktioniert, aber es war nicht möglich, eine gefälschte erste Migration (python manage.py --fake-initial) anzuwenden. Ich habe dies getan, da meine Tische (alte Tische) bereits erstellt wurden.

Schließlich funktionierte es für mich, entfernte neue Modelle (oder Modelländerungen) aus models.py und musste dann den Migrationsordner aller Apps löschen (oder zur sicheren Sicherung umbenennen) und python manage.py makemigrations für alle Apps ausführen. Dann python manage.py migrate --fake-initial. Das hat wie ein Zauber funktioniert. Sobald die anfängliche Migration für alle Apps erstellt wurde und die anfängliche Migration vorgetäuscht wurde, wurden neue Modelle hinzugefügt und der regulären Prozess von makemigrations gefolgt und die Migration für diese App durchgeführt. Die Änderungen wurden jetzt erkannt und alles lief gut.

Ich habe nur daran gedacht, es hier zu teilen, wenn jemand dasselbe Problem hat (mit schemamigrations von South für seine Apps), könnte es ihnen helfen :)

./manage makemigrations
./manage migrate

Migrationen protokollieren Änderungen an der Datenbank. Wenn Sie also von nicht verwaltet zu verwaltet wechseln, müssen Sie sicherstellen, dass Ihre Datenbanktabelle auf dem neuesten Stand ist und sich auf das Modell bezieht, mit dem Sie sich befassen.

Wenn Sie sich noch im Dev-Modus befinden, habe ich mich entschieden, die Migrationsdateien in meiner IDE sowie in der Django_migrations-Tabelle, die sich auf mein Model bezieht, zu löschen und den obigen Befehl erneut auszuführen.

HINWEIS: Wenn Sie eine Migration haben, die mit _001 in Ihrer IDE & _003 in Ihrer Datenbank endet. Django kann nur sehen, ob Sie eine Migration mit _004 haben, die aktualisiert werden soll.

Die 2 (Code- und Db-Migrationen) sind miteinander verknüpft und arbeiten zusammen.

Glückliche Kodierung.

Vielleicht hilft das jemandem.

Ich habe meinen models.py gelöscht und erwartet, dass makemigrationsDeleteModel-Anweisungen erstellt.

Denken Sie daran,*.pyc-Dateien zu löschen!

Diese Antwort wurde hinzugefügt, da keine der anderen verfügbaren Optionen für mich funktionierte.

In meinem Fall passierte etwas noch seltsameres ( Django 1.7 Version ). In meiner models.py hatte ich eine "extra" Zeile am Ende meiner Datei (es war ein Leerzeichen.) Zeile) und als ich den Befehl python manage.py makemigrations ausführte, war das Ergebnis: "Keine Änderungen festgestellt".

Um das Problem zu beheben, löschte ich diese "leere Zeile" , die sich am Ende meiner models.py -Datei befand, und führte den Befehl erneut aus, alles wurde behoben und alle Änderungen an models vorgenommen. py wurden entdeckt!

Hatte dasselbe Problem Vergewissern Sie sich, welche Klassen Sie in models.py definiert haben, Sie müssen die models.Model-Klasse erben.

class Product(models.Model):
    title = models.TextField()
    description = models.TextField()
    price = models.TextField()

Möglicherweise müssen Sie die ersten Migrationen mit dem folgenden Befehl vortäuschen

python manage.py migrate --fake-initial