wake-up-neo.com

Django migrieren --fake und --fake-initial erklärt

Ich bin jetzt seit ungefähr 2 Jahren ein Benutzer von Django) und es gibt eine Funktion, die ich immer befürchtet habe: gefälschte Migrationen .

Ich habe so ziemlich überall gesucht und die meisten Informationen, die ich bekommen kann, stammen aus der Dokumentation , in der es heißt:

- Fälschung

Weist Django an, die Migrationen als angewendet oder nicht angewendet zu markieren, ohne jedoch SQL auszuführen, um das Datenbankschema zu ändern.

Dies ist für fortgeschrittene Benutzer vorgesehen, um den aktuellen Migrationsstatus direkt zu ändern, wenn sie Änderungen manuell anwenden. Seien Sie gewarnt, dass die Verwendung von --fake das Risiko birgt, die Migrationsstatustabelle in einen Zustand zu versetzen, in dem eine manuelle Wiederherstellung erforderlich ist, damit Migrationen ordnungsgemäß ausgeführt werden.

- gefälschte Initiale

Ermöglicht Django die anfängliche Migration einer App zu überspringen, wenn bereits alle Datenbanktabellen mit den Namen aller Modelle vorhanden sind, die von allen CreateModel-Vorgängen in dieser Migration erstellt wurden. Diese Option ist für die erstmalige Ausführung von Migrationen für a vorgesehen Datenbank, die die Verwendung von Migrationen vorbestanden hat: Diese Option prüft jedoch nicht, ob das Datenbankschema über die übereinstimmenden Tabellennamen hinaus übereinstimmt, und ist daher nur dann sicher zu verwenden, wenn Sie sicher sind, dass Ihr vorhandenes Schema mit dem übereinstimmt, was bei der ursprünglichen Migration aufgezeichnet wurde.

Ich habe eine allgemeine Vorstellung davon, warum man diese Funktion nutzen möchte. Aber ich verstehe den Teil nicht, in dem steht, dass dies nur für fortgeschrittene Benutzer bestimmt ist.

Kann jemand erklären, was sich hinter den Kulissen abspielt und warum eine manuelle Wiederherstellung erforderlich ist?.

[~ # ~] note [~ # ~]

Ich suche nicht nach den genauen rohen SQL-Abfragen, die ausgeführt werden, wenn eine Migration gefälscht wird. Ich suche nur eine allgemeine Vorstellung davon, was sich hinter den Kulissen abspielt, und vielleicht ein Beispiel dafür, warum das Fälschen einer Migration zu einem Zustand führen würde, in dem makemigrations nicht richtig funktioniert.

21
scharette

Dies hängt mit einem Datenbankproblem zusammen, das einem Zusammenführungskonflikt im Quellcode (git) ähnelt, wenn Sie zwei Zweige mit ähnlichen Modellen kombinieren oder zwischen ihnen wechseln müssen. Niemand mag es absichtlich.

Stellen Sie sich vor, Sie haben letzte Woche begonnen, eine Anwendung zu ändern, möglicherweise weil Sie einen Fehler gefunden oder die Anwendung um ein Feld oder eine Tabelle erweitert haben. Sie haben heute ein Update erhalten und haben ein Problem, da es eine Migration gibt, bei der ein Feld hinzugefügt wird, das sich noch in Ihrer Datenbank befindet, und Sie nur andere Teile dieser Migration anwenden können. Sie können den SQL-Inhalt der Migration anzeigen, indem Sie ausführen

./manage sqlmigrate some_app 0007_new_migration >customized-some_app-0007_new_migration.sql

vergleichen Sie den Inhalt mit der letzten Woche vorgenommenen Änderung und entfernen oder kommentieren Sie einen Befehl, der noch angewendet wird und nicht wiederholt werden kann. Führen Sie alle verbleibenden SQL-Anweisungen manuell aus. Markieren Sie, dass die Migration automatisch angewendet wird:

./manage migrate --fake some_app 0007_new_migration

Wenn Sie etwas kaputtmachen, kann Ihnen wahrscheinlich niemand weiterhelfen, da das Migrationssystem den aktuellen Stand der Datenbank nicht mehr kennt. Machen Sie deshalb ein Backup, schreiben Sie Notizen, verwenden Sie eine Sandbox und arbeiten Sie präzise.

EDIT: Die Migrationstabelle Django_migrations ist eine einfache Liste der in allen Apps angewendeten Migrationen. Zeilen in dieser Tabelle sollten immer mit der Datenbankstruktur synchronisiert sein. Migrationen können mit einem normalen migrate durchgeführt werden. (oder nicht angewendet durch eine umgekehrte Migration in einen älteren Zustand, normalerweise natürlich mit einigem Datenverlust) Eine gefälschte Migration wendet die Änderung nur auf die Tabelle Django_migrations an.

me => select * from Django_migrations;
 id | app      |          name           |            applied            
----+----------+-------------------------+-------------------------------
  1 | some_app | 0001_initial            | 2017-10-16 06:11:07.31249+02
  2 | some_app | 0002_auto_20171016_1905 | 2017-10-17 02:05:48.979295+02

Bei einer Migration (Datei) handelt es sich um eine Beschreibung der inkrementellen Änderung sowie um Informationen, mit denen der Unterschied zwischen models.py seit der letzten Migration, die beim Ausführen von makemigrations verglichen wird. Dies ist auch dann ausreichend, wenn einige Tabellen ursprünglich nicht verwaltet wurden und später verwaltet werden könnten. (Daher werden auch nicht verwaltete Tabellen aufgezeichnet.)

EDIT: Ein Beispiel: wie sqlmigrate mit --fake kann verwendet werden, um eine fehlerhafte Datenbank durch Migrationen zu reparieren (eine gelöschte Tabelle neu zu erstellen).

20
hynekcer