Django-Migrationen:Eine Einführung

Jetzt ansehen Dieses Tutorial enthält einen zugehörigen Videokurs, der vom Real Python-Team erstellt wurde. Sehen Sie es sich zusammen mit dem schriftlichen Tutorial an, um Ihr Verständnis zu vertiefen:Django Migrations 101

Seit Version 1.7 verfügt Django über eine integrierte Unterstützung für Datenbankmigrationen. In Django gehen Datenbankmigrationen normalerweise Hand in Hand mit Modellen:Immer wenn Sie ein neues Modell programmieren, generieren Sie auch eine Migration, um die erforderliche Tabelle in der Datenbank zu erstellen. Migrationen können jedoch noch viel mehr.

In vier Artikeln und einem Video erfahren Sie, wie Django-Migrationen funktionieren und wie Sie sie optimal nutzen können:

Teil 1:Django-Migrationen:Eine Einführung (aktueller Artikel)
Teil 2:Tiefer in Migrationen eintauchen
Teil 3:Datenmigrationen
Video:Django 1.7-Migrationen – Einführung

In diesem Artikel machen Sie sich mit Django-Migrationen vertraut und lernen Folgendes:

Wie man Datenbanktabellen erstellt, ohne SQL zu schreiben
So ändern Sie Ihre Datenbank automatisch, nachdem Sie Ihre Modelle geändert haben
An Ihrer Datenbank vorgenommene Änderungen rückgängig machen

Kostenloser Bonus: Klicken Sie hier, um Zugang zu einem kostenlosen Django Learning Resources Guide (PDF) zu erhalten, der Ihnen Tipps und Tricks sowie häufige Fallstricke zeigt, die Sie beim Erstellen von Python + Django-Webanwendungen vermeiden sollten.

Die Probleme, die Migrationen lösen

Wenn Sie neu bei Django oder der Webentwicklung im Allgemeinen sind, sind Sie möglicherweise nicht mit dem Konzept der Datenbankmigration vertraut, und es scheint nicht offensichtlich zu sein, warum sie eine gute Idee sind.

Lassen Sie uns zunächst schnell ein paar Begriffe definieren, um sicherzustellen, dass alle auf derselben Seite sind. Django wurde entwickelt, um mit einer relationalen Datenbank zu arbeiten, die in einem Verwaltungssystem für relationale Datenbanken wie PostgreSQL, MySQL oder SQLite gespeichert ist.

In einer relationalen Datenbank sind Daten in Tabellen organisiert. Eine Datenbanktabelle hat eine bestimmte Anzahl von Spalten, kann aber beliebig viele Zeilen haben. Jede Spalte hat einen bestimmten Datentyp, wie eine Zeichenfolge mit einer bestimmten maximalen Länge oder eine positive ganze Zahl. Die Beschreibung aller Tabellen mit ihren Spalten und ihren jeweiligen Datentypen wird als Datenbankschema bezeichnet.

Alle von Django unterstützten Datenbanksysteme verwenden die Sprache SQL, um Daten in einer relationalen Datenbank zu erstellen, zu lesen, zu aktualisieren und zu löschen. SQL wird auch verwendet, um die Datenbanktabellen selbst zu erstellen, zu ändern und zu löschen.

Die direkte Arbeit mit SQL kann ziemlich umständlich sein, daher wird Django mit einem objektrelationalen Mapper, kurz ORM, geliefert, um Ihnen das Leben zu erleichtern. Das ORM bildet die relationale Datenbank auf die Welt der objektorientierten Programmierung ab. Anstatt Datenbanktabellen in SQL zu definieren, schreiben Sie Django-Modelle in Python. Ihre Modelle definieren Datenbankfelder, die den Spalten in ihren Datenbanktabellen entsprechen.

Hier ist ein Beispiel dafür, wie eine Django-Modellklasse einer Datenbanktabelle zugeordnet wird:

Aber nur das Definieren einer Modellklasse in einer Python-Datei lässt eine Datenbanktabelle nicht auf magische Weise aus dem Nichts erscheinen. Das Erstellen der Datenbanktabellen zum Speichern Ihrer Django-Modelle ist die Aufgabe einer Datenbankmigration. Darüber hinaus muss bei jeder Änderung an Ihren Modellen, z. B. beim Hinzufügen eines Felds, auch die Datenbank geändert werden. Migrationen handhaben das auch.

Hier sind einige Möglichkeiten, wie Django-Migrationen Ihr Leben einfacher machen.

Datenbankänderungen ohne SQL vornehmen

Ohne Migrationen müssten Sie sich mit Ihrer Datenbank verbinden und eine Reihe von SQL-Befehlen eingeben oder ein grafisches Tool wie PHPMyAdmin verwenden, um das Datenbankschema jedes Mal zu ändern, wenn Sie Ihre Modelldefinition ändern wollten.

In Django werden Migrationen hauptsächlich in Python geschrieben, sodass Sie keine SQL-Kenntnisse benötigen, es sei denn, Sie haben wirklich fortgeschrittene Anwendungsfälle.

Vermeidung von Wiederholungen

Ein Modell zu erstellen und dann SQL zu schreiben, um die Datenbanktabellen dafür zu erstellen, wäre eine Wiederholung.

Migrationen werden aus Ihren Modellen generiert, um sicherzustellen, dass Sie sich nicht wiederholen.

Sicherstellen, dass Modelldefinitionen und das Datenbankschema synchronisiert sind

Normalerweise haben Sie mehrere Instanzen Ihrer Datenbank, zum Beispiel eine Datenbank für jeden Entwickler in Ihrem Team, eine Datenbank zum Testen und eine Datenbank mit Live-Daten.

Ohne Migrationen müssen Sie alle Schemaänderungen an jeder Ihrer Datenbanken vornehmen und nachverfolgen, welche Änderungen bereits an welcher Datenbank vorgenommen wurden.

Mit Django-Migrationen können Sie problemlos mehrere Datenbanken mit Ihren Modellen synchronisieren.

Verfolgen von Datenbankschemaänderungen in der Versionskontrolle

Ein Versionskontrollsystem wie Git eignet sich hervorragend für Code, aber nicht so sehr für Datenbankschemata.

Da Migrationen in Django reines Python sind, können Sie sie wie jeden anderen Code in ein Versionskontrollsystem einfügen.

Inzwischen sind Sie hoffentlich davon überzeugt, dass Migrationen ein nützliches und leistungsstarkes Werkzeug sind. Fangen wir an zu lernen, wie man diese Kraft entfesselt.

Ein Django-Projekt einrichten

In diesem Tutorial arbeiten Sie als Beispielprojekt an einer einfachen Bitcoin-Tracker-App.

Der erste Schritt ist die Installation von Django. So machen Sie das unter Linux oder macOS X mit einer virtuellen Umgebung:

$ python3 -m venv env
$ source env/bin/activate
(env) $ pip install "Django==2.1.*"
...
Successfully installed Django-2.1.3

Jetzt haben Sie eine neue virtuelle Umgebung erstellt und aktiviert sowie Django in dieser virtuellen Umgebung installiert.

Beachten Sie, dass Sie unter Windows env/bin/activate.bat ausführen würden statt source env/bin/activate um Ihre virtuelle Umgebung zu aktivieren.

Zur einfacheren Lesbarkeit enthalten Konsolenbeispiele den (env) nicht von nun an Teil der Eingabeaufforderung.

Wenn Django installiert ist, können Sie das Projekt mit den folgenden Befehlen erstellen:

$ django-admin.py startproject bitcoin_tracker
$ cd bitcoin_tracker
$ python manage.py startapp historical_data

Dadurch erhalten Sie ein einfaches Projekt und eine App namens historical_data . Sie sollten jetzt diese Verzeichnisstruktur haben:

bitcoin_tracker/
|
├── bitcoin_tracker/
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
|
├── historical_data/
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── migrations/
│   │   └── __init__.py
|   |
│   ├── models.py
│   ├── tests.py
│   └── views.py
|
└── manage.py

Innerhalb des bitcoin_tracker Verzeichnis gibt es zwei Unterverzeichnisse:bitcoin_tracker für projektweite Dateien und historical_data mit Dateien für die von Ihnen erstellte App.

Um nun ein Modell zu erstellen, fügen Sie diese Klasse in historical_data/models.py hinzu :

class PriceHistory(models.Model):
    date = models.DateTimeField(auto_now_add=True)
    price = models.DecimalField(max_digits=7, decimal_places=2)
    volume = models.PositiveIntegerField()

Dies ist das Grundmodell, um die Bitcoin-Preise im Auge zu behalten.

Vergessen Sie auch nicht, die neu erstellte App zu settings.INSTALLED_APPS hinzuzufügen . Öffnen Sie bitcoin_tracker/settings.py und hängen Sie historical_data an zur Liste INSTALLED_APPS , etwa so:

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'historical_data',
]

Die anderen Einstellungen sind für dieses Projekt in Ordnung. Dieses Tutorial geht davon aus, dass Ihr Projekt für die Verwendung einer SQLite-Datenbank konfiguriert ist, was die Standardeinstellung ist.

Migrationen erstellen

Nachdem das Modell erstellt wurde, müssen Sie zunächst eine Migration dafür erstellen. Sie können dies mit dem folgenden Befehl tun:

$ python manage.py makemigrations historical_data
Migrations for 'historical_data':
  historical_data/migrations/0001_initial.py
    - Create model PriceHistory

Hinweis: Angabe des Namens der Anwendung, historical_data , es ist optional. Wenn Sie es auslassen, werden Migrationen für alle Apps erstellt.

Dadurch wird die Migrationsdatei erstellt, die Django anweist, wie die Datenbanktabellen für die in Ihrer Anwendung definierten Modelle erstellt werden. Schauen wir uns noch einmal den Verzeichnisbaum an:

bitcoin_tracker/
|
├── bitcoin_tracker/
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
|
├── historical_data/
│   ├── migrations/
│   │   ├── 0001_initial.py
│   │   └── __init__.py
|   |
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── models.py
│   ├── tests.py
│   └── views.py
|
├── db.sqlite3
└── manage.py

Wie Sie sehen können, sind die migrations Verzeichnis enthält jetzt eine neue Datei:0001_initial.py .

Hinweis: Möglicherweise stellen Sie fest, dass das Ausführen von makemigrations Der Befehl hat auch die Datei db.sqlite3 erstellt , die Ihre SQLite-Datenbank enthält.

Wenn Sie versuchen, auf eine nicht vorhandene SQLite3-Datenbankdatei zuzugreifen, wird diese automatisch erstellt.

Dieses Verhalten ist einzigartig für SQLite3. Wenn Sie ein anderes Datenbank-Backend wie PostgreSQL oder MySQL verwenden, müssen Sie die Datenbank vorher selbst erstellen Ausführen von makemigrations .

Mit der dbshell können Sie einen Blick auf die Datenbank werfen Verwaltungsbefehl. In SQLite lautet der Befehl zum Auflisten aller Tabellen einfach .tables :

$ python manage.py dbshell
SQLite version 3.19.3 2017-06-27 16:48:08
Enter ".help" for usage hints.
sqlite> .tables
sqlite>

Die Datenbank ist noch leer. Das ändert sich, wenn Sie die Migration anwenden. Geben Sie .quit ein um die SQLite-Shell zu verlassen.

Migrationen anwenden

Sie haben die Migration nun erstellt, aber um tatsächlich Änderungen in der Datenbank vorzunehmen, müssen Sie sie mit dem Verwaltungsbefehl migrate anwenden :

$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, historical_data, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying historical_data.0001_initial... OK
  Applying sessions.0001_initial... OK

Hier ist viel los! Laut Ausgabe wurde Ihre Migration erfolgreich angewendet. Aber wo kommen all die anderen Migrationen her?

Merken Sie sich die Einstellung INSTALLED_APPS ? Einige der anderen dort aufgeführten Apps enthalten auch Migrationen und die migrate Der Verwaltungsbefehl wendet standardmäßig die Migrationen für alle installierten Apps an.

Schauen Sie sich noch einmal die Datenbank an:

$ python manage.py dbshell
SQLite version 3.19.3 2017-06-27 16:48:08
Enter ".help" for usage hints.
sqlite> .tables
auth_group                    django_admin_log
auth_group_permissions        django_content_type
auth_permission               django_migrations
auth_user                     django_session
auth_user_groups              historical_data_pricehistory
auth_user_user_permissions
sqlite>

Jetzt gibt es mehrere Tische. Ihre Namen geben Ihnen eine Vorstellung von ihrem Zweck. Die Migration, die Sie im vorherigen Schritt generiert haben, hat die historical_data_pricehistory erstellt Tisch. Untersuchen wir es mit dem .schema Befehl:

sqlite> .schema --indent historical_data_pricehistory
CREATE TABLE IF NOT EXISTS "historical_data_pricehistory"(
  "id" integer NOT NULL PRIMARY KEY AUTOINCREMENT,
  "date" datetime NOT NULL,
  "price" decimal NOT NULL,
  "volume" integer unsigned NOT NULL
);

Das .schema Befehl gibt den CREATE aus Anweisung, die Sie ausführen würden, um die Tabelle zu erstellen. Der Parameter --indent formatiert es schön. Auch wenn Sie mit der SQL-Syntax nicht vertraut sind, können Sie erkennen, dass das Schema der historical_data_pricehistory Tabelle spiegelt die Felder der PriceHistory wider Modell.

Es gibt eine Spalte für jedes Feld und eine zusätzliche Spalte id für den Primärschlüssel, den Django automatisch erstellt, es sei denn, Sie geben explizit einen Primärschlüssel in Ihrem Modell an.

Folgendes passiert, wenn Sie migrate ausführen Befehl erneut:

$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, historical_data, sessions
Running migrations:
  No migrations to apply.

Gar nichts! Django merkt sich, welche Migrationen bereits angewendet wurden, und versucht nicht, sie erneut auszuführen.

Es ist erwähnenswert, dass Sie auch die migrate einschränken können Verwaltungsbefehl an eine einzelne App:

$ python manage.py migrate historical_data
Operations to perform:
 Apply all migrations: historical_data
Running migrations:
 No migrations to apply.

Wie Sie sehen können, wendet Django jetzt nur Migrationen für historical_data an App.

Wenn Sie die Migrationen zum ersten Mal ausführen, ist es eine gute Idee, alle Migrationen anzuwenden, um sicherzustellen, dass Ihre Datenbank die erforderlichen Tabellen für die Funktionen enthält, die Sie möglicherweise als selbstverständlich ansehen, wie Benutzerauthentifizierung und Sitzungen.

Modellwechsel

Ihre Modelle sind nicht in Stein gemeißelt. Ihre Modelle werden sich ändern, wenn Ihr Django-Projekt mehr Funktionen erhält. Sie können Felder hinzufügen oder entfernen oder ihre Typen und Optionen ändern.

Wenn Sie die Definition eines Modells ändern, müssen auch die Datenbanktabellen geändert werden, in denen diese Modelle gespeichert sind. Wenn Ihre Modelldefinitionen nicht mit Ihrem aktuellen Datenbankschema übereinstimmen, werden Sie höchstwahrscheinlich auf einen django.db.utils.OperationalError stoßen .

Wie ändern Sie also die Datenbanktabellen? Durch Erstellen und Anwenden einer Migration.

Beim Testen Ihres Bitcoin-Trackers stellen Sie fest, dass Sie einen Fehler gemacht haben. Leute verkaufen Bruchteile eines Bitcoins, also das Feld volume sollte vom Typ DecimalField sein statt PositiveIntegerField .

Ändern wir das Modell so, dass es folgendermaßen aussieht:

class PriceHistory(models.Model):
    date = models.DateTimeField(auto_now_add=True)
    price = models.DecimalField(max_digits=7, decimal_places=2)
    volume = models.DecimalField(max_digits=7, decimal_places=3)

Ohne Migrationen müssten Sie die SQL-Syntax herausfinden, um ein PositiveIntegerField umzuwandeln in ein DecimalField . Glücklicherweise übernimmt Django das für Sie. Sagen Sie ihm einfach, dass er Migrationen durchführen soll:

$ python manage.py makemigrations
Migrations for 'historical_data':
  historical_data/migrations/0002_auto_20181112_1950.py
    - Alter field volume on pricehistory

Hinweis: Der Name der Migrationsdatei (0002_auto_20181112_1950.py ) basiert auf der aktuellen Zeit und wird anders sein, wenn Sie auf Ihrem System folgen.

Jetzt wenden Sie diese Migration auf Ihre Datenbank an:

$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, historical_data, sessions
Running migrations:
  Applying historical_data.0002_auto_20181112_1950... OK

Die Migration wurde erfolgreich angewendet, sodass Sie dbshell verwenden können um zu überprüfen, ob die Änderungen wirksam waren:

$ python manage.py dbshell
SQLite version 3.19.3 2017-06-27 16:48:08
Enter ".help" for usage hints.
sqlite> .schema --indent historical_data_pricehistory
CREATE TABLE IF NOT EXISTS "historical_data_pricehistory" (
  "id" integer NOT NULL PRIMARY KEY AUTOINCREMENT,
  "date" datetime NOT NULL,
  "price" decimal NOT NULL,
  "volume" decimal NOT NULL
);

Wenn Sie das neue Schema mit dem zuvor gesehenen Schema vergleichen, werden Sie feststellen, dass der Typ des volume Spalte hat sich von integer geändert zu decimal um die Änderung der volume widerzuspiegeln -Feld im Modell aus PositiveIntegerField zu DecimalField .

Migrationen auflisten

Wenn Sie wissen möchten, welche Migrationen in einem Django-Projekt vorhanden sind, müssen Sie sich nicht durch die migrations wühlen Verzeichnisse Ihrer installierten Apps. Sie können die showmigrations verwenden Befehl:

$ ./manage.py showmigrations
admin
 [X] 0001_initial
 [X] 0002_logentry_remove_auto_add
 [X] 0003_logentry_add_action_flag_choices
auth
 [X] 0001_initial
 [X] 0002_alter_permission_name_max_length
 [X] 0003_alter_user_email_max_length
 [X] 0004_alter_user_username_opts
 [X] 0005_alter_user_last_login_null
 [X] 0006_require_contenttypes_0002
 [X] 0007_alter_validators_add_error_messages
 [X] 0008_alter_user_username_max_length
 [X] 0009_alter_user_last_name_max_length
contenttypes
 [X] 0001_initial
 [X] 0002_remove_content_type_name
historical_data
 [X] 0001_initial
 [X] 0002_auto_20181112_1950
sessions
 [X] 0001_initial

Hier werden alle Apps im Projekt und die jeder App zugeordneten Migrationen aufgelistet. Außerdem wird ein großes X gesetzt neben den bereits durchgeführten Migrationen.

Für unser kleines Beispiel, die showmigrations Der Befehl ist nicht besonders aufregend, aber er ist praktisch, wenn Sie mit der Arbeit an einer vorhandenen Codebasis beginnen oder in einem Team arbeiten, in dem Sie nicht die einzige Person sind, die Migrationen hinzufügt.

Migrationen rückgängig machen

Jetzt wissen Sie, wie Sie Änderungen an Ihrem Datenbankschema vornehmen, indem Sie Migrationen erstellen und anwenden. An einem bestimmten Punkt möchten Sie vielleicht Änderungen rückgängig machen und zu einem früheren Datenbankschema zurückkehren, weil Sie:

Möchten Sie eine Migration testen, die ein Kollege geschrieben hat
Erkennen Sie, dass eine von Ihnen vorgenommene Änderung eine schlechte Idee war
Arbeiten Sie parallel an mehreren Funktionen mit unterschiedlichen Datenbankänderungen
Sie möchten eine Sicherung wiederherstellen, die erstellt wurde, als die Datenbank noch ein älteres Schema hatte

Glücklicherweise müssen Migrationen keine Einbahnstraße sein. In vielen Fällen können die Auswirkungen einer Migration rückgängig gemacht werden, indem eine Migration rückgängig gemacht wird. Um eine Migration rückgängig zu machen, müssen Sie migrate aufrufen mit dem Namen der App und dem Namen der Migration vorher die Migration, die Sie rückgängig machen möchten.

Wenn Sie die Migration rückgängig machen möchten 0002_auto_20181112_1950 in Ihren historical_data App müssen Sie 0001_initial übergeben als Argument für migrate Befehl:

$ python manage.py migrate historical_data 0001_initial
Operations to perform:
  Target specific migration: 0001_initial, from historical_data
Running migrations:
  Rendering model states... DONE
  Unapplying historical_data.0002_auto_20181112_1950... OK

Die Migration wurde rückgängig gemacht, was bedeutet, dass die Änderungen an der Datenbank rückgängig gemacht wurden.

Durch das Aufheben einer Migration wird ihre Migrationsdatei nicht entfernt. Beim nächsten Ausführen von migrate Befehl, wird die Migration erneut angewendet.

Achtung: Verwechseln Sie das Rückgängigmachen von Migrationen nicht mit dem Vorgang zum Rückgängigmachen, den Sie von Ihrem bevorzugten Texteditor gewohnt sind.

Nicht alle Datenbankoperationen können vollständig rückgängig gemacht werden. Wenn Sie ein Feld aus einem Modell entfernen, eine Migration erstellen und anwenden, entfernt Django die entsprechende Spalte aus der Datenbank.

Wenn Sie diese Migration rückgängig machen, wird die Spalte neu erstellt, aber die Daten, die in dieser Spalte gespeichert waren, werden nicht wiederhergestellt!

Wenn Sie sich mit Migrationsnamen befassen, erspart Ihnen Django einige Tastenanschläge, da Sie nicht gezwungen werden, den vollständigen Namen der Migration zu buchstabieren. Es braucht gerade genug Namen, um es eindeutig zu identifizieren.

Im vorherigen Beispiel hätte es gereicht, python manage.py migrate historical_data 0001 auszuführen .

Migrationen benennen

Im obigen Beispiel hat Django basierend auf dem Zeitstempel einen Namen für die Migration gefunden – etwa *0002_auto_20181112_1950 . Wenn Sie damit nicht zufrieden sind, können Sie den --name verwenden Parameter, um einen benutzerdefinierten Namen bereitzustellen (ohne .py Erweiterung).

Um das auszuprobieren, müssen Sie zuerst die alte Migration entfernen. Sie haben die Anwendung bereits aufgehoben, sodass Sie die Datei sicher löschen können:

$ rm historical_data/migrations/0002_auto_20181112_1950.py

Jetzt können Sie es mit einem aussagekräftigeren Namen neu erstellen:

$ ./manage.py makemigrations historical_data --name switch_to_decimals

Dadurch wird die gleiche Migration wie zuvor erstellt, außer mit dem neuen Namen 0002_switch_to_decimals .

Schlussfolgerung

Sie haben in diesem Tutorial einiges an Grund und Boden behandelt und die Grundlagen von Django-Migrationen gelernt.

Zur Erinnerung:Die grundlegenden Schritte zur Verwendung von Django-Migrationen sehen folgendermaßen aus:

Modell erstellen oder aktualisieren
Führen Sie ./manage.py makemigrations <app_name> aus
Führen Sie ./manage.py migrate aus alles migrieren oder ./manage.py migrate <app_name> um eine einzelne App zu migrieren
Bei Bedarf wiederholen

Das ist es! Dieser Workflow funktioniert die meiste Zeit, aber wenn die Dinge nicht wie erwartet funktionieren, wissen Sie auch, wie Sie Migrationen auflisten und rückgängig machen.

Wenn Sie Ihre Datenbanktabellen zuvor mit handgeschriebenem SQL erstellt und geändert haben, sind Sie jetzt viel effizienter geworden, indem Sie diese Arbeit an Django-Migrationen delegieren.

Im nächsten Tutorial dieser Reihe tauchen Sie tiefer in das Thema ein und erfahren, wie Django-Migrationen im Hintergrund funktionieren.

Prost!