Es ist also ziemlich einfach, verwirrt zu werden, wenn
Sie zum ersten Mal Datenmodelle,
Migrationen und die Datenbank selbst betrachten.
Und so möchte ich das etwas genauer durchgehen.
Die Makemigrationen lesen also die
models.py Dateien und dann
erstellt es, was Migrationen genannt werden.
Und das Wichtigste ist, dass dies von
der Liste der Anwendungen in settings.py geleitet wird.
Also, wenn Sie eine neue Sache machen und eine neue Anwendung erstellen,
und Sie die Models-Datei bearbeiten und versuchen,
eine Makemigrationen auszuführen und es sieht
nichts wie, was hat es gerade getan?
Nun, haben Sie Ihre settings.py bearbeitet? Weil es
eine Sache namens installierte Apps in Ihrer settings.py gibt.
Migrationen sind nun datenbankübergreifend portabel.
Dies bedeutet, dass die Migration
eine logische Beschreibung dessen ist, wie die Tabellen
aussehen sollten, und sie sind eine Evolution.
Was sie bedeuten, ist wie die erste Version
dieser Tabelle, von der
ersten models.py, als Migrationen zum ersten Mal ausgeführt wurden, 001.
Und dann, wenn Sie models.py ändern
und eine Migration erneut ausführen,
betrachtet es die Änderungen von
der Migration 001 zu models.py und dann 002,
und dann ist 002 nicht so, als würde alles auslöschen und von vorne anfangen,
es ist wie: „Oh warte, du hast gerade eine Spalte hinzugefügt.
Ich gehe weiter und füge diese Spalte hinzu.“ Aber es ist
nicht so gemacht, dass es tatsächlich SQL ist.
Migrationen sind also selbst
Art Python-ähnlich und sie sind datenbankübergreifend portabel,
was bedeutet, dass Sie auf
Ihrem Computer SQLite verwenden
könnten, und in der Produktion können Sie MySQL verwenden, und
die Migrationen sind für
beide gleich, weil sie nur sagen:
„Hier ist die Spalten, hier sind die Typen,
hier ist, was sie sein sollen.“
Nun, kontrastieren Sie das mit einem migrate-Befehl.
Der Befehl migrate liest
alle Migrationen und
weiß dann, mit welcher Datenbank er spricht,
und führt die SQL-Befehle aus, um
die notwendigen Tabellen zu erstellen und/oder die notwendigen Tabellen zu entwickeln.
So sieht es aus und sagt oh, hier ist
die erste Migration, hier ist die zweite Migration,
hier ist die dritte Migration. Ich mache die Tabelle,
ich ändere die Tabelle, ich
ändere die Tabelle, ich ändere die Tabelle, und am Ende der gesamten Migration durchläuft die Migration dann
alle Migrationen und hat dann
eine Datenbanktabelle, die
die Summe der Migrationen
widerspiegelt, die auch die neueste Datei models.py.
Es ist also etwas komplex.
Es hat mit Datenbank-Portabilität zu tun
und die Tatsache, dass wir
die tragbaren Teile davon
von den nicht tragbaren Teilen trennen wollen.
Also, wenn man sich die Makemigrationen anschaut
und hier ein DJ4e-Samples,
mein kleines Beispielmaterial,
gibt es viele Modelle drin.
Und wenn Sie sich die ganze models.py ansehen,
sehen Sie, dass
Sie für jede Anwendung im dj4e-Beispielprojekt eine models.py Datei sehen und das ist ein
Python-Code, das ist Klasse, Buch, bla, bla, bla, bla.
Das ist sehr portabel und so
sehen wir in unserem Python-Code, in unserem Django-Code, das Datenbankmodell.
Und wenn Sie die Makemigration ausführen,
erzeugt das diese Migrationsdateien und
sie sind wie autos/migrations/001_initial.py usw.
und so sehen Sie einige von denen, die ich hier habe,
gibt es tatsächlich zwei von ihnen.
Also hat es irgendwie die erste gemacht
und dann muss ich die Modelldatei geändert haben,
und dann habe ich Makemigrationen erneut ausgeführt und es hat aufgezeichnet
, wie sich dieses Modell von
der ersten Version der
Modelldatei zur zweiten Version geändert hat.
Sie können sich diese ansehen, aber nicht bearbeiten,
Sie können sie in GitHub einchecken, diese aber nicht bearbeiten.
Aber sieh mal an. Sie sind eine sehr tragbare Darstellung.
Sie sehen irgendwie aus wie die Datei models.py.
Du sollst sie nicht ändern,
du sollst sie
mit Makemigrationen erzeugen. Und wieder
können diese in GitHub gehen.
Nun liest die
Migration im Grunde alle diese Migrationsdateien und
nicht nur eine, aber wenn
es eine Sequenz von Migrationsdateien gibt,
wendet sie alle nach Bedarf in der Reihenfolge an.
Und wenn die Datenbank
die erste und zweite Migration angewendet hat,
aber nicht die dritte,
weiß sie das und sagt: „Weißt du was,
ich werde nur diese Datenbank optimieren,
die bereits existiert, die bereits ausgeführt wird,
und dann eine Spalte hinzufügen oder
die Breite einer Spalte ändern oder was immer es ist
, dass Sie gebeten haben, getan zu werden, indem Sie Ihre models.py bearbeiten.“
Wenn die Migration abgeschlossen ist,
erhalten Sie dann eine ganze Reihe von Tabellen
in Ihrer Datenbank, und sie basieren alle auf
dem Namen der Anwendung und dem Namen
des Modells in der Anwendung.
Und so irgendwo hier drin ist bookone_book,
bookone_instance und bookone_lang.
Die sitzen alle da.
Und so sind das alle Tische. Und wir
haben uns diese Tische vorher angesehen.
Aber das ist die Migration, die
von all den kleinen Migrationen geht,
die über alle Anwendungen in diesem Projekt verteilt sind und dann
eine Datenbank zusammenfügt, die all diese Dinge enthält.
Und ich sage immer wieder, dass es bei den
Migrationen um Evolution geht,
denn wenn
Sie hier einen Blick werfen, sehen Sie eine kleine Tabelle namens
django_migrations und was Django in
dieser django_migrations-Tabelle macht, erinnert sich daran, welche
dieser Migrationen bereits auf
diese Datenbank, so wie sie die Migrationen durchläuft
, heißt es: „Oh, hier ist
eine, die in dieser Datenbank noch nicht fertig ist,
also muss ich die Datenbank nur ein wenig optimieren.“
So erinnert es sich an die Migrationen, die durchgeführt wurden.
Es ist ziemlich faszinierend und
in diesen kleinen Anwendungen
müssen wir nicht immer so klug sein.
Also manchmal, was Sie tun wollen
, ist einfach wie: „Ich bin verwirrt,
ich werde die Makemigrate erneut
ausführen“, weil Sie nicht wirklich produzieren,
Sie tun es einfach wirklich immer und immer wieder,
damit Sie die Makemigrate erneut ausführen können.
Und die Art, wie Sie dies tun, ist, dass Sie
im Grunde einfach die Datei löschen,
Sie können diese Dateien löschen.
Ich würde alle löschen, die mit Null beginnen.
Wenn Sie Makemigration erneut ausführen möchten, führen Sie
einfach Makemigrationen erneut aus,
löschen Sie alle, die mit Null beginnen,
und dies ist in der Anwendung,
Migrationen, und dann werden Sie alle diese los,
und dann können Sie
Makemigrationen erneut ausführen und es
wird Ihre Datei models.py lesen,
und dann wird es führt alle
notwendigen Dinge aus, um die Migrationsdatei neu zu erstellen.
Genau, jetzt ist das nicht die Datenbank,
das sind die Anweisungen, wie man die Datenbank erstellt, okay?
So führen Sie Makemigrate erneut aus.
Sie können migrieren von Grund auf ausführen,
das ist eigentlich einfacher.
So können Sie
die Migrationen für eine Anwendung löschen, und ich habe das getan,
einfach den Bookone hier gelöscht,
das ist, was ich getan habe und von vorn angefangen habe,
aber Sie können alle Migrationen und die ganze
Datenbank und alles löschen, indem Sie einfach
die Datei in
diesem Fall entfernen, weil wir Wenn SQLite ausgeführt wird,
löschen Sie einfach die Datei
rm db.sqlite aus
, weil nach der Migration alles in dieser Datei endet.
Also, wenn du das auslöschst, ist es weg.
Nun haben Sie vielleicht ein Administratorkonto oder
etwas erstellt und Sie werden das auch löschen.
Du wirst die Daten löschen,
du wirst die Tische löschen, alles ist weg.
Das ist eine Sache, die ich an SQLite mag,
du entfernst diese eine Datei und es ist buchstäblich alles weg.
Und dann führen Sie python3 manage.py
migrieren erneut aus und es liest
alle Migrationen und macht Sie eine schöne,
saubere, perfekte leere Datenbank.
Also, wenn Sie irgendwie stecken bleiben
und Sie keine Angst haben, Ihre Daten zu verlieren,
was in den meisten der ersten Programmierer
ist es in Ordnung, Ihre SQLite-Sache zu löschen
und migrieren erneut auszuführen.
Probieren Sie es einfach aus.
Wie ich schon sagte, wenn Sie ein Admin-Konto erstellt
haben, müssen Sie es wieder schaffen,
aber das ist das Schlimmste, was Sie tun können,
zumindest in diesen frühen Anwendungen.
Nun, da wir darüber gesprochen haben,
wie man ein Datenmodell entwickelt,
wie man es in Django models.py kodiert,
wie man Migrationen durchführt und wie man
Dinge migriert und wie man eine Datenbank daraus herstellt,
werden wir jetzt über die Art von
Python-Code sprechen, den Sie
ausführen können, um diese Modelle in der Datenbank.
( MUSIK)