django.db.migrations.exceptions.InconsistentMigrationHistory

79

Wenn ich python manage.py migratemein Django-Projekt ausführe , wird folgende Fehlermeldung angezeigt:

Traceback (most recent call last):
File "manage.py", line 22, in <module>
execute_from_command_line(sys.argv)
File "/home/hari/project/env/local/lib/python2.7/site-     packages/django/core/management/__init__.py", line 363, in execute_from_command_line
utility.execute()
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 355, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/base.py", line 283, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/base.py", line 330, in execute
output = self.handle(*args, **options)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 86, in handle
executor.loader.check_consistent_history(connection)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/db/migrations/loader.py", line 298, in check_consistent_history
connection.alias,
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency account.0001_initial on database 'default'.

Ich habe ein Benutzermodell wie unten:

class User(AbstractUser):
    place = models.CharField(max_length=64, null=True, blank=True)
    address = models.CharField(max_length=128, null=True, blank=True)

Wie kann ich dieses Problem lösen?

Hari Krishnan
quelle
4
Löschen Sie zuerst alle Tabellen aus der Datenbank, löschen Sie alle Dateien aus dem Migrationsordner mit Ausnahme von init.py und führen Sie dann
migrate
Wie lösche ich alle Tabellen?
Hari Krishnan
Welche Datenbank benutzt du?
Exprator
Yah. Ich habe es gelöscht und jetzt funktioniert es.
Hari Krishnan
Für mich war das Problem, weil ich eine Migration hatte, die davon abhing 'ipn', '__latest__'. Ich habe gerade überprüft die Reihenfolge oder angewendet Migrationen mit select * from django_migrations, dann verändert __latest__durch , 'ipn', '0007_auto_20160219_1135'und das Problem ist verschwunden.
Ruben Alves

Antworten:

43

Ihre Tabelle django_migrations in Ihrer Datenbank ist die Ursache für Inkonsistenzen, und das Löschen aller Migrationen nur aus dem lokalen Pfad funktioniert nicht.

Sie müssen die Tabelle django_migrations aus Ihrer Datenbank abschneiden und dann erneut versuchen, die Migrationen anzuwenden. Es sollte funktionieren, aber wenn es nicht funktioniert, führen Sie erneut Makemigrationen aus und migrieren Sie dann.

Hinweis: Vergessen Sie nicht, eine Sicherungskopie Ihrer Daten zu erstellen.

Arpit Solanki
quelle
5
Hat nicht funktioniert. Als ich versuchte zu migrieren, wurde beanstandet, dass bereits eine Beziehung besteht. Beachten Sie, dass Sie die Tabelle django_migrations mit diesem Befehl abschneiden können:> python manage.py shell `` `aus django.db import connection cursor = connection.cursor () cursor.execute (" TRUNCATE TABLE django_migrations ")` `` Und Sie können anzeigen Die Migrationstabelle sieht folgendermaßen aus: `` `von django.db.migrations.recorder import MigrationRecorder MigrationRecorder.Migration.objects.all ()` ``
Almenon
Dies ist eine schreckliche Idee mit einer hohen Wahrscheinlichkeit eines Datenverlusts. Siehe meine Antwort unten.
tbm
100

Da Sie ein benutzerdefiniertes Benutzermodell verwenden, können Sie zunächst einen Kommentar abgeben

INSTALLED_APPS = [
...
#'django.contrib.admin',
...
]

in Ihren Installed_Apps-Einstellungen. Dann renne

python manage.py migrate.

Wenn Sie fertig sind, kommentieren Sie

'django.contrib.admin'
Jackson
quelle
3
Wow du bist ein Lebensretter. Das hat mir viel Zeit gespart. Genau die Antwort benötigt. Vielen Dank!!
Arun
Ja, das hat mein Problem gelöst! Ich habe das Standardbenutzermodell in das abstrakte Benutzermodell geändert und nach allen Migrationen wurde ein Fehler angezeigt. Aber als ich das versuchte, löste ich mein Problem!
Mevaka
27
Es funktioniert nicht bei mir. Die Fehlermeldung lautet "Keine App mit Label-Administrator installieren". Muss ich zuerst alle Dateien in Migrationen löschen? weiß jemand, wie man es löst? Danke ~
Geschickte Pfote
1
Unten finden Sie eine Antwort von user9414732.
Rexcirus
13
Vergessen Sie nicht den Kommentarpfad ('admin /', admin.site.urls) in urls.py
Vladimir
68

Beginnen wir mit der Behebung des Problems mit den meisten Antworten auf dieser Seite:

Sie müssen Ihre Datenbank niemals löschen, wenn Sie das Migrationssystem von Django korrekt verwenden, und Sie sollten Migrationen niemals löschen, sobald sie festgeschrieben sind

Die beste Lösung für Sie hängt nun von einer Reihe von Faktoren ab, darunter, wie erfahren Sie mit Django sind, wie gut Sie das Migrationssystem verstehen und wie wertvoll die Daten in Ihrer Datenbank sind.

Kurz gesagt, es gibt zwei Möglichkeiten, wie Sie Migrationsfehler beheben können.

  1. Nehmen Sie die nukleare Option. Warnung: Dies ist nur eine Option, wenn Sie alleine arbeiten. Wenn andere Personen von vorhandenen Migrationen abhängig sind, können Sie diese nicht einfach löschen.

    • Löschen Sie alle Ihre Migrationen und erstellen Sie ein neues Set mit python3 -m manage makemigrations. Dies sollte alle Probleme beseitigen, die Sie mit Abhängigkeiten oder Inkonsistenzen bei Ihren Migrationen hatten.
    • Löschen Sie Ihre gesamte Datenbank. Dadurch werden alle Probleme behoben, die Sie mit Inkonsistenzen zwischen Ihrem tatsächlichen Datenbankschema und dem Schema hatten, das Sie basierend auf Ihrem Migrationsverlauf haben sollten, und alle Probleme, die Sie mit Inkonsistenzen zwischen Ihrem Migrationsverlauf und Ihren vorherigen Migrationsdateien hatten [dies ist was das InconsistentMigrationHistorybeschwert sich über].
    • Erstellen Sie Ihr Datenbankschema mit neu python3 -m manage migrate
  2. Bestimmen Sie die Ursache des Fehlers und beheben Sie ihn, da die Ursache (aus Erfahrung) mit ziemlicher Sicherheit etwas Dummes ist, das Sie getan haben. (Im Allgemeinen, weil Sie nicht verstehen, wie das Migrationssystem richtig verwendet wird). Basierend auf den Fehlern, die ich verursacht habe, gibt es drei Kategorien.

    1. Inkonsistenzen mit Migrationsdateien. Dies ist ziemlich häufig, wenn mehrere Personen an einem Projekt arbeiten. Hoffentlich stehen Ihre Änderungen nicht in Konflikt und makemigrations --mergekönnen dieses Problem lösen. Andernfalls muss jemand seine Migrationen zum Verzweigungspunkt zurücksetzen, um dies zu beheben.
    2. Inkonsistenzen zwischen Ihrem Schema und Ihrem Migrationsverlauf. Um dies zu verwalten, hat jemand entweder das Datenbankschema manuell bearbeitet oder Migrationen gelöscht. Wenn sie eine Migration gelöscht haben, setzen Sie ihre Änderungen zurück und schreien Sie sie an. Sie sollten niemals Migrationen löschen, wenn andere von ihnen abhängen. Wenn sie das Datenbankschema manuell bearbeitet haben, setzen Sie ihre Änderungen zurück und schreien Sie sie dann an. Django verwaltet das Datenbankschema, sonst niemand.
    3. Inkonsistenzen zwischen Ihrem Migrationsverlauf und Ihren Migrationsdateien. [Dies ist das InconsistentMigrationHistoryProblem, unter dem der Fragesteller leidet, und das, unter dem ich gelitten habe, als ich auf dieser Seite ankam]. Um dies zu verwalten, hat jemand entweder manuell mit der django_migrationsTabelle herumgespielt oder eine Migration gelöscht, nachdem sie angewendet wurde. Um dies zu beheben, müssen Sie herausfinden, wie die Inkonsistenz entstanden ist, und sie manuell beheben. Wenn Ihr Datenbankschema korrekt ist und nur Ihr Migrationsverlauf falsch ist, können Sie die django_migrationsTabelle manuell bearbeiten , um dies zu beheben. Wenn Ihr Datenbankschema falsch ist, müssen Sie es auch manuell bearbeiten, um es an das anzupassen, was es sein sollte.

Aufgrund Ihrer Beschreibung des Problems und der von Ihnen ausgewählten Antwort gehe ich davon aus, dass Sie alleine arbeiten, neu bei Django sind und sich nicht um Ihre Daten kümmern. Die nukleare Option könnte also für Sie richtig sein.

Wenn Sie sich nicht in dieser Situation befinden und der obige Text wie Kauderwelsch aussieht, empfehle ich, die Mailingliste des Django-Benutzers um Hilfe zu bitten. Es gibt dort sehr hilfreiche Leute, die Ihnen helfen können, das spezifische Chaos zu lösen, in dem Sie sich befinden.

Haben Sie Vertrauen, Sie können diesen Fehler beheben, ohne nuklear zu werden!

Airs
quelle
1
Für Interessenten: In meinem Fall hatte ich eine temporäre Migration erstellt, um Tabellen in App B zu erstellen, während ich darauf wartete, dass mein Mitarbeiter benutzerdefinierte Migrationen zum Verschieben der Tabellen von App A nach App B abschließt. Als mein Mitarbeiter fertig war, habe ich meine zurückgesetzt temporäre Migration und ging, um Migrationen anzuwenden. Bam Fehler. Ich habe nicht nur vergessen, meine temporäre Migration aufzuheben, sondern es auch geschafft, die temporäre Migration mit der tatsächlichen zu benennen. Auf das Migrationssystem wurde die Migration von App B, 0001_initialdie von der Migration von App A abhing, 00XX_autoirgendwie vor ihrer Abhängigkeit angewendet!
Airs
2
So schrecklich das auch klingt, es war leicht zu lösen. Meine Datenbank hatte das richtige Schema, sodass ich sie nur manuell 'A' '00XX_auto'zur django_migrationsTabelle hinzufügen musste , sodass mein Verlauf widerspiegelte, dass die Änderungen in dieser Migration angewendet wurden. Kompliziert, aber nicht so schwer, wenn Sie das Problem gelöst haben.
Airs
Sie können Migrationen nicht einfach löschen, sondern müssen auch den Pycache löschen
JonPizza
Ich bin in diese Essiggurke geraten, weil ich eine Reihe von Nicht-Django-Tabellen mit Anfangsdaten hatte, die die meisten meiner Modelle managed = Falseenthielten. Als ich mich entschied, ORM seine Arbeit machen zu lassen und zu verwalteten Modellen zu wechseln (um meine Tests zum Laufen zu bringen), begann mein ganzer "Spaß".
cjm
Sie sollten Migrationen unbedingt löschen, wenn Ihr Team beschließt, 0001 bis 0230 oder wie viele hundert Migrationen Sie auch haben: Sie begehen die gequetschte Migration, warten, bis CI / CD sie anwendet, und sobald das Produkt vollständig aufgeholt hat , löschen Sie sie die ursprünglichen Dateien 0001 _... bis 0230 _..., weil sie nichts mehr tun, und Sie aktualisieren die Squash-Migrationen zurück, um nichts mehr zu sagen replaces. Wenn Sie die alten Migrationen beibehalten, wird das Dev-Leben für Ihr Team nur dann zur Hölle, wenn jemand herausfinden muss, welche der zig 0002 Migrationen die echte ist.
Mike 'Pomax' Kamermans
37

Hier erfahren Sie, wie Sie dies richtig lösen können.

Führen Sie die folgenden Schritte in Ihrem Migrationsordner im Projekt aus:

  1. Löschen Sie die _pycache_- und die 0001_initial-Dateien.
  2. Löschen Sie die Datei db.sqlite3 aus dem Stammverzeichnis (achten Sie darauf, dass alle Ihre Daten gelöscht werden).
  3. auf dem Terminal laufen:
      python manage.py makemigrations
      python manage.py migrate

Voila.

Dr. Younes Henni
quelle
1
Was ist, wenn wir nicht löschen möchten und im Produktionsmodus. Auch ich benutze nicht sqllite, es ist MySQL in unserem Server. Was ist die bessere Methode, ohne Daten zu verlieren?
Bishwas Bhandari
30

Dies passierte mir in einem neuen Projekt, nachdem ich ein benutzerdefiniertes Benutzermodell gemäß der Empfehlung in den Django-Dokumenten hinzugefügt hatte.

Wenn Sie ein neues Projekt starten, wird dringend empfohlen, ein benutzerdefiniertes Benutzermodell einzurichten, auch wenn das Standardbenutzermodell für Sie ausreicht.

Folgendes habe ich getan, um das Problem zu lösen.

  1. Löschen Sie die Datenbank db.sqlite3.
  2. Löschen Sie den Ordner app / migrations.

Kommentieren Sie per @jackson vorübergehend django.contrib.admin aus.

INSTALLED_APPS = [
...
#‘django.contrib.admin’,
...
]

Kommentieren Sie auch die Admin-Site in urls.py aus:

urlpatterns = [
    path('profile/', include('restapp.urls')),
    #path('admin/', admin.site.urls),
]

Wenn Sie den Pfad ('admin /') nicht auskommentieren, wird beim Ausführen die Fehlermeldung "LookupError: Keine installierte App mit der Bezeichnung 'admin'" angezeigt

python manage.py migrate

Kommentieren Sie nach Abschluss der Migrationen beide oben genannten Punkte aus.

user9414732
quelle
26

Problem

django.db.migrations.exceptions.InconsistentMigrationHistory: Die Migration admin.0001_initial wird vor ihrem Abhängigkeitskonto.0001_initial auf die Datenbank 'default' angewendet.

So können wir zuerst die Datenbank ohne admin (admin.0001_initial) migrieren.

Führen Sie nach der Migration der Abhängigkeit die zu migrierenden Befehle aus admin.0001_initial.

Lösung

  1. Entfernen Sie 'django.contrib.admin' aus INSTALLED_APPS in settings.py.
  2. Befehle ausführen:

App-Name der Python-Datei verwalten.py makemigrations

Python verwalten.py migrieren App-Namen

  1. Fügen Sie 'django.contrib.admin' zu INSTALLED_APPS in der Datei settings.py hinzu.
  2. Befehle erneut ausführen:

App-Name der Python-Datei verwalten.py makemigrations

Python verwalten.py migrieren App-Namen

Kun Shi
quelle
7
Für mich führt das Entfernen von 'django.contrib.admin' aus INSTALLED_APPS und das Ausführen von Makemigrationen zuLookupError: No installed app with label 'admin'.
Szymon Przedwojski
4
Gehen Sie zu urls.py und kommentieren Sie URLs mit admin
Gautam Kumar
2

Löschen Sie einfach die SQLite-Datei oder führen Sie das Löschen der Datenbank 'python manage.py flush' aus und führen Sie dann makemigrations- bzw. migrate-Befehle aus.

Arun
quelle
2

wenn Sie ein neues Django-Projekt erstellen und ausführen

python manage.py migrieren

Der Django erstellt standardmäßig 10 Tabellen für Sie, darunter eine auth_user-Tabelle und zwei beginnen mit auth_user.

Wenn Sie ein benutzerdefiniertes Benutzermodell erstellen möchten, das von AbstractUser geerbt wurde, tritt dieses Problem mit der folgenden Fehlermeldung auf:

django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency account.0001_initial on database 'default'.

Ich löse dieses Problem, indem ich meine gesamte Datenbank lösche und eine neue erstelle. Und dies ersetzte die drei Tabellen, die ich erwähnte.

hcf1425
quelle
2
Okay, was ist, wenn ich meine Datenbank nicht löschen möchte? Gibt es eine verfügbare Lösung?
Iulian Pinzaru
2

Sichern Sie Ihre Datenbank, bevor Sie weitere Schritte ausführen. Dann sichern Sie es erneut.

Entfernen Sie benutzerdefinierten Benutzermodellcode aus dem Weg, deaktivieren Sie Ihr benutzerdefiniertes Modell und Ihre App in den Einstellungen und gehen Sie dann wie folgt vor:

python manage.py dumpdata auth --natural-primary --natural-foreign > auth.json
python manage.py migrate auth zero  # This will also revert out the admin migrations

Fügen Sie dann Ihr benutzerdefiniertes Modell hinzu, legen Sie es in den Einstellungen fest und aktivieren Sie die App erneut. Stellen Sie sicher, dass Sie noch keine Migrationen für diese App haben.

Dann:

python manage.py makemigrations <your-app>
python manage.py migrate
python manage.py loaddata auth.json  # Assumes your user-model isn't TOO dissimilar to the standard one.

Erledigt!

tbm
quelle
2

Gelöst durch Kommentieren vor der Migration in settings.py 'django.contrib.admin' und in urls.py , ('admin/', admin.site.urls). Kommentar nach der Migration auskommentieren

NaSir HuSSaiN
quelle
Postleitzahl (Ersatz) in Skriptform und oben, wo der Code beginnt, beginnt jeder Block mit einem Dateinamen, der ein Skript darstellt. Wie Sie Ihre Antwort gepostet haben, ist für mich verwirrend.
ZF007
@ ZF007 Entschuldigung für die Verwirrung. Ich bin ein bisschen neu in StackOverflow, daher habe ich nicht verstanden, wie ich eine Antwort
posten soll
1

Löschen Sie zuerst alle Migrationen und db.sqlite3-Dateien und führen Sie die folgenden Schritte aus:

$ ./manage.py makemigrations myapp 
$ ./manage.py squashmigrations myapp 0001(may be differ)

Löschen Sie die alte Migrationsdatei und schließlich.

$ ./manage.py migrate
Shivam Singhal
quelle
1

Ihr Fehler ist im Wesentlichen:

Migration "B" is applied before its dependency "A" on database 'default'.

Sanity Check : Öffnen Sie zunächst Ihre Datenbank und sehen Sie sich die Datensätze in der Tabelle 'django_migrations' an. Die Aufzeichnungen sollten in chronologischer Reihenfolge aufgeführt sein (z. B. A, B, C, D ...).

Stellen Sie sicher, dass der Name der im Fehler aufgeführten "A" -Migration mit dem Namen der in der Datenbank aufgeführten "A" -Migration übereinstimmt. (Sie können unterschiedlich sein, wenn Sie zuvor manuell Migrationsdateien bearbeitet, gelöscht oder umbenannt haben.)

Um dies zu beheben , benennen Sie Migration A entweder in der Datenbank um oder benennen Sie den Dateinamen um. ABER stellen Sie sicher, dass die Änderungen mit denen anderer Entwickler in Ihrem Team in ihren Datenbanken übereinstimmen (oder dass die Änderungen mit denen in Ihrer Produktionsdatenbank übereinstimmen).

Michael Romrell
quelle
1

Wenn Sie an einer leeren Datenbank arbeiten, können die Migrationen für die Konto- App vor allen anderen App-Migrationen schnell behoben werden .

$ ./manage.py migrate account

Und dann:

$ ./manage.py migrate
Duilio
quelle
0

Wenn sich diese Ausnahme zeigte, während Sie versuchen, Ihr eigenes Benutzermodell anstelle des Standards zu erstellen, befolgen Sie diese Anweisung.
Ich habe festgestellt, dass mein Problem behoben ist, indem Sie diese Anweisung Schritt für Schritt befolgen:

  1. Erstellen Sie ein benutzerdefiniertes Benutzermodell, das mit auth.User identisch ist, nennen Sie es Benutzer (so viele-zu-viele-Tabellen behalten denselben Namen) und setzen Sie db_table = 'auth_user' (damit dieselbe Tabelle verwendet wird).
  2. Werfen Sie alle Ihre Migrationen weg
  3. Erstellen Sie einen neuen Satz von Migrationen
  4. Opfere ein Huhn, vielleicht zwei, wenn du Angst hast; Erstellen Sie auch eine Sicherungskopie Ihrer Datenbank
  5. Schneiden Sie die Tabelle django_migrations ab
  6. Wenden Sie die neuen Migrationen fälschlicherweise an
  7. Deaktivieren Sie db_table, nehmen Sie andere Änderungen am benutzerdefinierten Modell vor, generieren Sie Migrationen und wenden Sie diese an

Es wird dringend empfohlen, dies in einer Datenbank zu tun, die Fremdschlüsseleinschränkungen erzwingt. Versuchen Sie dies nicht auf SQLite auf Ihrem Laptop und erwarten Sie, dass es auf Postgres auf den Servern funktioniert!

ncopiy
quelle
Könnten Sie Ihrer Antwort eine Zusammenfassung oder ein Zitat aus dem verlinkten Artikel hinzufügen?
Collin M. Barrett
0

Wenn Sie AUTH_USER_MODE L in settings.py wie folgt einstellen :

AUTH_USER_MODEL = 'custom_user_app_name.User'

Sie sollten diese Zeile kommentieren, bevor Sie makemigration ausführen und Befehle migrieren . Dann können Sie diese Zeile erneut auskommentieren.

Erfan Tahriri
quelle
3
Leider führt dies zu Fehlern für mich, zB:accounts.CustomUser.groups: (fields.E304) Reverse accessor for 'CustomUser.groups' clashes with reverse accessor for 'User.groups'. HINT: Add or change a related_name argument to the definition for 'CustomUser.groups' or 'User.groups'.
Szymon Przedwojski
0

Wenn Sie ein neues Projekt erstellen und keine Apps verwenden, führen Sie das aus

python manage.py migrate

Der Django erstellt standardmäßig 10 Tabellen.

Wenn Sie ein Kundenbenutzermodell erstellen möchten, das danach erbt AbstractUser, tritt dieses Problem wie folgt auf:

django.db.migrations.exceptions.InconsistentMigrationHistory: Die Migration admin.0001_initial wird vor ihrem Abhängigkeitskonto.0001_initial auf die Datenbank 'default' angewendet.

Schließlich lösche ich meine gesamten Datenbanken und starte

hcf1425
quelle
0

Ich habe dies bei der Migration von Wagtail 2.0 auf 2.4 festgestellt, habe es jedoch einige Male gesehen, als eine Drittanbieter-App eine Migration nach Ihrer aktuellen Version, jedoch vor der Version, auf die Sie migrieren, unterdrückt.

Die schockierend einfache Lösung in diesem Fall ist zumindest:

./manage.py migrate
./manage.py makemigrations
./manage.py migrate

Führen Sie also eine einzelne Migration aus, bevor Sie versuchen, Migrationen durchzuführen.

Rick Westera
quelle
0

Neben Benutzerfehlern gibt es noch einen weiteren Grund, der zu solchen Problemen führen kann: Ein bekanntes Problem mit Django, wenn es um gequetschte Migrationen geht.

Wir haben eine Reihe von Migrationen, die in Python 2.7 + Django 1.11 einwandfrei funktionieren. Wird ausgeführt makemigrationsoder migratefunktioniert immer wie es sollte usw., auch (zu Testzwecken), wenn die Datenbank neu erstellt wird.

Als wir jedoch ein Projekt auf Python 3.6 verschieben (derzeit mit demselben Django 1.11), habe ich versucht herauszufinden, warum dieselben Migrationen nur beim ersten Ausführen einwandfrei funktionieren. Danach führt jeder Versuch, etwas auszuführen, makemigrationsoder führt nur migratezu dem Fehler:

django.db.migrations.exceptions.InconsistentMigrationHistory

wobei die Migration foo.0040-thingvor ihrer Abhängigkeit angewendet wird foo.0038-something-squashed-0039-somethingelse(wir haben nur diese eine gequetschte Migration ... der Rest ist viel einfacher).

Was mich eine Weile nervt, ist, warum dies nur unter Python 3 passiert. Wenn die Datenbank wirklich inkonsistent ist, sollte dies die ganze Zeit passieren. Dass die Migrationen bei der ersten Anwendung einwandfrei zu funktionieren scheinen, war ebenso verwirrend.

Nach langem Suchen (einschließlich des vorliegenden Q & A-Threads) bin ich auf den oben genannten Django-Fehlerbericht gestoßen . Unsere Squash-Migration hat tatsächlich das bPräfix in der replacesZeile verwendet (z.replaces = [(b'', 'foo.0038-defunct'),.......]

Nachdem ich die bPräfixe aus der replacesZeile entfernt hatte, funktionierte alles normal.

MartyMacGyver
quelle
0

Dieses Problem tritt meistens auf, wenn Sie das Benutzermodell nach der ersten Migration erweitern. Denn wenn Sie den Abstract-Benutzer erweitern, werden grundlegende Felder erstellt, die im Modell vorhanden waren, z. B. E-Mail, Vorname usw.

Auch dies gilt für jedes abstrakte Modell in Django.

Eine sehr einfache Lösung hierfür besteht darin, entweder eine neue Datenbank zu erstellen und dann Migrationen anzuwenden oder [Sie werden in diesem Fall alle Daten gelöscht.] Dieselbe Datenbank zu löschen und Migrationen erneut anzuwenden .

Mayank Pratap Singh
quelle
0

Sichern Sie zunächst Ihre Daten. (Kopieren Sie Ihre Datenbankdatei).

Löschen Sie sqlite.db und auch den Migrationsordner .

Führen Sie dann die folgenden Befehle aus:

./manage.py makemigrations APP_NAME
./manage.py migrate APP_NAME

Stellen Sie nach dem Löschen der DB-Datei und des Migrationsordners sicher, dass Sie den Anwendungsnamen nach den Migrationsbefehlen schreiben.

imansdn
quelle
0

Okay, bevor Sie etwas Seltsames oder Nukleares tun, lassen Sie zuerst Ihre Datenbank fallen und erstellen Sie sie neu.

Bei Verwendung von POsgres -

DROP SCHEMA public CASCADE;
CREATE SCHEMA PUBLIC;

Dann machen Sie einfach Ihre Migrationen neu

./manage.py migrate

Dies ist die grundlegendste Lösung, die normalerweise Abhilfe schafft. Machen Sie die Migrationen nicht einfach neu, bis sie absolut notwendig sind.

JoCee
quelle
3
"irgendetwas Seltsames oder Nukleares" und dann "zuerst einfach Ihre Datenbank löschen und neu erstellen". Wenn das Löschen der Datenbank nicht als nuklear angesehen wird, würde ich es hassen zu sehen, was ist.
tbm
0

Ich muss meine Datenbank ablegen und dann makemigrations ausführen und erneut migrieren, damit dies meinerseits behoben werden kann.

Flavins
quelle
0

Löschen Sie den Migrationsordner und db.sqlite3 und geben Sie den Befehl cmd python manage.py ein

Moncef Banouri
quelle
1
Während dies das Problem beheben kann, können Sie einige Informationen darüber bereitstellen, warum es das Problem auch beheben wird?
Bob0the0mighty
Weil du bereits eine SQL-Datenbank mit einer Struktur und einigen Daten darin erstellt hast und wenn du einige Änderungen
vornimmst, die deine
0

Die Reihenfolge INSTALLED_APPSscheint wichtig zu sein. Wenn Sie Ihre letzten Arbeiten immer ganz oben / am Anfang der Liste platzieren, werden sie in Bezug auf django.contrib.admin immer ordnungsgemäß geladen. Das Verschieben meiner Werke an den Anfang der INSTALLED_APPSListe hat dieses Problem für mich behoben. Der Grund, warum Kun Shis Lösung möglicherweise funktioniert hat, war, dass die Migrationen in einer anderen Reihenfolge ausgeführt wurden.

altdelete
quelle
0

django.db.migrations.exceptions.InconsistentMigrationHistory # Beim Erstellen eines benutzerdefinierten Benutzermodells

Ich hatte heute das gleiche Problem und keine der oben genannten Lösungen funktionierte. Dann dachte ich, ich würde alle Daten aus meiner lokalen PostgreSQL-Datenbank mit diesem folgenden Befehl löschen

-- Drop everything from the PostgreSQL database.

DO $$
DECLARE
        q TEXT;
        r RECORD;
BEGIN
        -- triggers
        FOR r IN (SELECT pns.nspname, pc.relname, pt.tgname
                FROM pg_catalog.pg_trigger pt, pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
                WHERE pns.oid=pc.relnamespace AND pc.oid=pt.tgrelid
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
                    AND pt.tgisinternal=false
            ) LOOP
                EXECUTE format('DROP TRIGGER %I ON %I.%I;',
                    r.tgname, r.nspname, r.relname);
        END LOOP;
        -- constraints #1: foreign key
        FOR r IN (SELECT pns.nspname, pc.relname, pcon.conname
                FROM pg_catalog.pg_constraint pcon, pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
                WHERE pns.oid=pc.relnamespace AND pc.oid=pcon.conrelid
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
                    AND pcon.contype='f'
            ) LOOP
                EXECUTE format('ALTER TABLE ONLY %I.%I DROP CONSTRAINT %I;',
                    r.nspname, r.relname, r.conname);
        END LOOP;
        -- constraints #2: the rest
        FOR r IN (SELECT pns.nspname, pc.relname, pcon.conname
                FROM pg_catalog.pg_constraint pcon, pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
                WHERE pns.oid=pc.relnamespace AND pc.oid=pcon.conrelid
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
                    AND pcon.contype<>'f'
            ) LOOP
                EXECUTE format('ALTER TABLE ONLY %I.%I DROP CONSTRAINT %I;',
                    r.nspname, r.relname, r.conname);
        END LOOP;
        -- indicēs
        FOR r IN (SELECT pns.nspname, pc.relname
                FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
                WHERE pns.oid=pc.relnamespace
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
                    AND pc.relkind='i'
            ) LOOP
                EXECUTE format('DROP INDEX %I.%I;',
                    r.nspname, r.relname);
        END LOOP;
        -- normal and materialised views
        FOR r IN (SELECT pns.nspname, pc.relname
                FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
                WHERE pns.oid=pc.relnamespace
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
                    AND pc.relkind IN ('v', 'm')
            ) LOOP
                EXECUTE format('DROP VIEW %I.%I;',
                    r.nspname, r.relname);
        END LOOP;
        -- tables
        FOR r IN (SELECT pns.nspname, pc.relname
                FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
                WHERE pns.oid=pc.relnamespace
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
                    AND pc.relkind='r'
            ) LOOP
                EXECUTE format('DROP TABLE %I.%I;',
                    r.nspname, r.relname);
        END LOOP;
        -- sequences
        FOR r IN (SELECT pns.nspname, pc.relname
                FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
                WHERE pns.oid=pc.relnamespace
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
                    AND pc.relkind='S'
            ) LOOP
                EXECUTE format('DROP SEQUENCE %I.%I;',
                    r.nspname, r.relname);
        END LOOP;
        -- extensions (only if necessary; keep them normally)
        FOR r IN (SELECT pns.nspname, pe.extname
                FROM pg_catalog.pg_extension pe, pg_catalog.pg_namespace pns
                WHERE pns.oid=pe.extnamespace
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
            ) LOOP
                EXECUTE format('DROP EXTENSION %I;', r.extname);
        END LOOP;
        -- aggregate functions first (because they depend on other functions)
        FOR r IN (SELECT pns.nspname, pp.proname, pp.oid
                FROM pg_catalog.pg_proc pp, pg_catalog.pg_namespace pns, pg_catalog.pg_aggregate pagg
                WHERE pns.oid=pp.pronamespace
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
                    AND pagg.aggfnoid=pp.oid
            ) LOOP
                EXECUTE format('DROP AGGREGATE %I.%I(%s);',
                    r.nspname, r.proname,
                    pg_get_function_identity_arguments(r.oid));
        END LOOP;
        -- routines (functions, aggregate functions, procedures, window functions)
        IF EXISTS (SELECT * FROM pg_catalog.pg_attribute
                WHERE attrelid='pg_catalog.pg_proc'::regclass
                    AND attname='prokind' -- PostgreSQL 11+
            ) THEN
                q := 'CASE pp.prokind
                        WHEN ''p'' THEN ''PROCEDURE''
                        WHEN ''a'' THEN ''AGGREGATE''
                        ELSE ''FUNCTION''
                    END';
        ELSIF EXISTS (SELECT * FROM pg_catalog.pg_attribute
                WHERE attrelid='pg_catalog.pg_proc'::regclass
                    AND attname='proisagg' -- PostgreSQL ≤10
            ) THEN
                q := 'CASE pp.proisagg
                        WHEN true THEN ''AGGREGATE''
                        ELSE ''FUNCTION''
                    END';
        ELSE
                q := '''FUNCTION''';
        END IF;
        FOR r IN EXECUTE 'SELECT pns.nspname, pp.proname, pp.oid, ' || q || ' AS pt
                FROM pg_catalog.pg_proc pp, pg_catalog.pg_namespace pns
                WHERE pns.oid=pp.pronamespace
                    AND pns.nspname NOT IN (''information_schema'', ''pg_catalog'', ''pg_toast'')
            ' LOOP
                EXECUTE format('DROP %s %I.%I(%s);', r.pt,
                    r.nspname, r.proname,
                    pg_get_function_identity_arguments(r.oid));
        END LOOP;
        -- nōn-default schemata we own; assume to be run by a not-superuser
        FOR r IN (SELECT pns.nspname
                FROM pg_catalog.pg_namespace pns, pg_catalog.pg_roles pr
                WHERE pr.oid=pns.nspowner
                    AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast', 'public')
                    AND pr.rolname=current_user
            ) LOOP
                EXECUTE format('DROP SCHEMA %I;', r.nspname);
        END LOOP;
        -- voilà
        RAISE NOTICE 'Database cleared!';
END; $$;

Danach können Sie den Befehl django für Migrationen ausführen

python manage.py makemigrations
python manage.py migrate

Und das wird auf jeden Fall funktionieren. Vielen Dank.

Faisal Nazik
quelle