python start Django 1.7-"Keine Migrationen anwenden", wenn die Migration nach Makemigrationen ausgeführt wird



python django how to start (9)

Ich benutze Django1.7 mit Mezzanine. Ich erstelle ein einfaches Profil (gemäß der Mezzanine-Dokumentation), das in separaten App-Profilen gespeichert ist:

class RoadmapProfile(models.Model):
    user = models.OneToOneField("auth.User")
    fullname = models.CharField(max_length=100, verbose_name="Full name")

Die Erstellung von Migrationen führt zurück:

  Migrations for 'profiles':
      0001_initial.py:
        - Create model RoadmapProfile

Wenn ich "Migrationsprofile" starte:

Operations to perform:
  Apply all migrations: profiles
Running migrations:
  No migrations to apply.

Das Problem ist, wenn ich versuche, eine Seite zu öffnen, die sich auf mezzanine.accounts bezieht (z. B. Konto aktualisieren), stürzt sie ab mit:

OperationalError at /accounts/update/

no such column: profiles_roadmapprofile.fullname

Was habe ich falsch gemacht?


Answer #1

Ich bin ein Django-Neuling und habe das gleiche Problem durchgemacht. Diese Antworten haben bei mir nicht funktioniert. Ich wollte mitteilen, wie ich das Problem behoben habe. Wahrscheinlich würde es jemandem viel Zeit sparen.

Situation:

Ich nehme Änderungen an einem Modell vor und möchte diese Änderungen auf die Datenbank anwenden.

Was ich getan habe:

Auf Shell ausführen:

python manage.py makemigrations app-name
python manage.py migrate app-name

Was ist passiert:

  • In der DB werden keine Änderungen vorgenommen

  • Aber wenn ich das DB-Schema überprüfe, bleibt es das alte

Grund:

  • Beim Ausführen von python manage.py migrate app-name überprüft Django in der Tabelle django_migrations in der Datenbank, welche Migrationen bereits angewendet wurden, und überspringt diese Migrationen.

Was ich probiert habe:

Löschen Sie den Datensatz mit app = "my-app-name" aus dieser Tabelle ( delete from django_migrations where app = "app-name" ). Löschen Sie den Migrationsordner und führen Sie python manage.py makemigration my-app-name , und python manage.py migrate my-app-name . Dies wurde von der am meisten bewerteten Antwort vorgeschlagen. Das funktioniert aber auch nicht.

Warum?

Da es eine vorhandene Tabelle gab und was ich erstelle, war dies eine "anfängliche Migration", so dass Django entscheidet, dass die erste Migration bereits angewendet wurde (weil sie sieht, dass die Tabelle bereits vorhanden ist). Das Problem ist, dass die vorhandene Tabelle ein anderes Schema hat.

Lösung 1:

Löschen Sie die vorhandene Tabelle (mit dem alten Schema), führen Sie erste Migrationen durch und übernehmen Sie sie erneut. Dies wird funktionieren (es hat für mich funktioniert), da wir eine "anfängliche Migration" haben und es keine Tabelle mit demselben Namen in unserer Datenbank gab. (Tipp: Ich habe python manage.py migrate my-app-name zero zu python manage.py migrate my-app-name zero , um die Tabellen schnell in der python manage.py migrate my-app-name zero )

Problem? Möglicherweise möchten Sie die Daten in der vorhandenen Tabelle beibehalten. Sie möchten sie nicht ablegen und alle Daten verlieren.

Lösung 2:

  1. Erstellen Sie eine erste Migration mit demselben Schema wie die vorhandene Tabelle. Führen Sie dazu die folgenden Schritte aus:

    • Passen Sie Ihre models.py an die aktuelle Tabelle in Ihrer Datenbank an

    • Alle Dateien in "Migrationen" löschen

    • Führen Sie python manage.py makemigrations your-app-name

  2. Löschen Sie in django_migrations alle Felder mit django_migrations.app = your-app-name Wie dies geschieht, hängt davon ab, welche Datenbank Sie verwenden. Beispiel für MySQL: delete from django_migrations where app = "your-app-name";

  3. Passen Sie Ihre models.py an das neue Schema an (z. B. das Schema, das Sie jetzt benötigen).

  4. Machen Sie eine neue Migration, indem Sie python manage.py makemigrations your-app-name

  5. Führen Sie python manage.py migrate your-app-name

Das funktioniert für mich. Und ich konnte die vorhandenen Daten beibehalten.

Weitere Gedanken:

Der Grund, warum ich all diese Probleme durchging, war, dass ich die Dateien in Some-app / migrations / (den Migrationsdateien) gelöscht habe. Daher sind diese Migrationsdateien und meine Datenbank nicht konsistent. Ich würde also versuchen, diese Migrationsdateien nicht zu ändern, es sei denn, ich weiß wirklich, was ich mache.


Answer #2

Das Problem hier sind gefälschte Migrationen. Grundsätzlich ist in Ihrer Datenbank die aus Ihrem Modell erstellte Tabelle nicht vorhanden. Irgendwann in der Zeit, in der diese Tabelle vorhanden war, gab es ein altes Update oder was auch immer es war. Das Problem ist, dass django diese Migrationen bereits durchgeführt hat, also sollten die Tabellen existieren, um Migrationen zu übersehen, aber den Fehler "table_doesnt_exist" in Admin zu erhalten.

Lösung:

1. Speichern Sie alle Daten dieses Modells.

2.- Greifen Sie auf Ihre Datenbank zu und führen Sie diese Abfrage aus.

 SELECT * FROM django_migrations;

3. Holen Sie die ID aus der Liste, die aus der Abfrage generiert wurde. Dies sind Migrationen, die Django bisher migriert hat, daher sollten TABLES EXIST. In Ihrem Fall würde ich nach einer Zeile mit dem Namen roadmapprofile suchen , da dies der Name Ihres Modells ist.

4.- Jetzt können wir diese Zeile mit den IDs aus dieser Tabelle löschen.

 DELETE FROM django_migrations where django_migrations.id in (value_id1, value_id2);

Ersetzen Sie value_id1 und value_id2 durch entsprechende IDs. Es kann nur eine oder mehrere sein. Machen Sie sich also keine Sorgen, wenn Sie nicht mehr als eine ID sehen. Dies bedeutet, dass nur ein Modell unter der aktuellen App vorhanden ist.

5. Migrieren Sie die App auf Null

 manage.py migrate <app_name> zero

6.- Löschen Sie alle Migrationsdateien im App-Migrationsordner

7.- Migrationen erstellen

 manage.py makemigrations

8.- Sobald Sie diese Registrierungen gelöscht haben und manage.py migrate ausführen; Django wird gezwungen sein, Migrationen für diese Modelle auszuführen, da "MIGRATIONS WON'T EXIST" für diese Modelle fehlt.

 manage.py migrate

Das ist es. Sie sollten keine Probleme haben, wenn Sie diese Anweisungen befolgen. Übrigens sollten Sie keine Daten aus anderen Modellen verlieren, da Sie nur Tabellen migrieren und aktualisieren, die sich auf diese bestimmten Modelle beziehen.


Answer #3

Für mich funktionierte keine der angebotenen Lösungen. Es stellte sich heraus, dass ich verschiedene Einstellungen für die Migration ( manage.py ) und die Ausführung ( wsgi.py ) verwendet habe. In manage.py definierte manage.py verwendeten eine lokale Datenbank. In den Einstellungen von manage.py jedoch eine Produktionsdatenbank verwendet. Daher wurde eine Produktionsdatenbank niemals migriert . Mit:

django-admin migrate

für die Migration erwies sich als besser, da Sie die here verwendeten Einstellungen angeben müssen.

  • Stellen Sie sicher, dass Sie bei der Migration immer dieselbe Datenbank verwenden wie beim Ausführen !

Answer #4

1- führen Sie python manage.py makemigrations <appname>

2- run python manage.py sqlmigrate <appname> <migrationname> - Sie finden den Migrationsnamen im Migrationsordner unter "Anwendungsname" (natürlich ohne ".py" -Erweiterung).

3- Kopieren Sie den gesamten Text des Ergebnisses # aller generierten SQL-Befehle
4- Gehen Sie zu Ihrem DB Ide und fügen Sie ihn als neue Abfrage ein und führen Sie ihn aus

Nun werden alle Änderungen auf Ihre Datenbank angewendet


Answer #5

Ich hatte das gleiche Problem. Stellen Sie sicher, dass der Migrationsordner der App erstellt wurde (YOURAPPNAME / Migrationen). Löschen Sie den Ordner und geben Sie die Befehle ein:

python manage.py migrate --fake
python manage.py makemigrations <app_name>
python manage.py migrate --fake-initial

Ich habe diese Zeilen in models.py in jede Klasse eingefügt:

class Meta:
    app_label = '<app_name>'

Das hat mein Problem gelöst.


Answer #6

In meinem Fall habe ich so geschrieben:

python manage.py makemigrations - yourappname python manage.py makemigrations App- yourappname

python manage.py migrate yourappname

oder:

Django verfolgt alle angewandten Migrationen in der Tabelle django_migrations. Löschen Sie also einfach alle Zeilen in der Tabelle django_migrations, die sich auf Ihre App beziehen, wie:

DELETE FROM django_migrations WHERE app=' your-app-name '

und dann mache:

python manage.py makemigrations python manage.py migrate


Answer #7

Klingt, als wäre Ihre ursprüngliche Migration gefälscht worden, weil die Tabelle bereits vorhanden war (wahrscheinlich mit einem veralteten Schema):

https://docs.djangoproject.com/en/1.7/topics/migrations/#adding-migrations-to-apps

"Dies führt zu einer neuen anfänglichen Migration für Ihre App. Wenn Sie nun die Migration ausführen, erkennt Django, dass Sie eine anfängliche Migration haben und die Tabellen, die es erstellen möchte, bereits vorhanden sind, und markiert die Migration als bereits angewendet ."

Andernfalls würden Sie einen Fehler ohne solche Tabelle erhalten :)

[Bearbeiten] Haben Sie die Tabelle für angewendete Migrationen aufgeräumt? Dies ist auch eine häufige Ursache für nicht angewendete Migrationen.


Answer #8
  1. Löschen Sie in der MySQL-Datenbank die Zeile 'profiles' aus der Tabelle 'django_migrations' .
  2. Löschen Sie alle Migrationsdateien im Migrationsordner.
  3. Versuchen Sie es erneut mit dem python manage.py makemigrations und python manage.py migrate .

Answer #9

@ phanhuy152 hat die beste Antwort. Nur um meine zwei Cents hinzuzufügen:

Seine Lösung ist:

  1. Migrationsverlauf in DB löschen
  2. migrations löschen
  3. Bearbeiten Sie Ihr Modell so, dass es vor der Änderung konsistent mit der Datenbank ist
  4. makemigrations zum Wiederherstellen des ursprünglichen Status der Migrationsdateien
  5. Ändern Sie dann das Modell nach Ihren Wünschen
  6. wieder makemigrations
  7. migrate , um Aktualisierungen auf die Tabelle anzuwenden.

In meinem Fall habe ich jedoch mehrere Modelle in der Datei models.py , und im letzten Schritt beschwert sich Django, dass Table xxx already exists , da die ursprünglichen Migrationsdateien die xxx-Tabelle erneut erstellen möchten, wenn dies nicht der Fall ist (und möchte nicht) andere Tabellen löschen.

In diesem Fall müssen wir, um die Daten zu schützen, Django anweisen, sie bei der migrate in Ruhe zu lassen. Wir machen einfach: (Nehmen wir an, dass Klasse A die ist, die wir ändern, und Klasse B, C bleiben gleich):

models.py :

from django.db import models

class A(models.Models):
    ...

class B(models.Models):
    class Meta:
        managed = False   # tell Django to leave this class alone

    ...

class C(models.Models):
    class Meta:
        managed = False   # tell Django to leave this class alone

Fügen Sie diese Zeilen hinzu, nachdem wir die anfänglichen Migrationen erstellt haben.

So ist der Prozess jetzt:

  1. ...
  2. ...
  3. ...
  4. ...
  5. Fügen Sie managed = False zu anderen Klassen hinzu
  6. makemigrations , um Meta Änderungen anzuwenden. Sie werden so etwas sehen:

Ausgabe:

Migrations for 'backEnd':
  backEnd/migrations/0002_auto_20180412_1654.py
    - Change Meta options on toid
    - Change Meta options on tprocessasinc
    - Change Meta options on tservers
    - Change Meta options on tsnmpserver
  1. migrate , um sie in der DB anzuwenden
  2. Ändern Sie jetzt Ihr Modell: Fügen Sie ein Feld hinzu, ändern Sie den Typ usw.
  3. wieder migrate
  4. Löschen Sie die Meta Klasse, damit Django wieder andere Klassen verwalten kann. makemigrations , wieder migrate .

Jetzt haben Sie alle Struktur und Daten Ihrer Modelle, ohne den zuvor in der Datenbank gespeicherten Teil zu verlieren.





django