Wie man Django-Modelle erstellt

Einführung

In diesem Tutorial erstellen wir Django-Modelle, die die Felder und Verhaltensweisen der Blog-Anwendungsdaten definieren, die wir speichern werden. Diese Modelle ordnen Ihre Django-Anwendungsdaten der Datenbank zu. Django verwendet diese Modelle, um mithilfe der Object Relational Mapping (ORM) API Datenbanktabellen zu generieren.

Voraussetzungen

Dieses Tutorial ist Teil der Django-Entwicklungsreihe und eine Fortsetzung dieser Reihe.

Falls Sie diese Serie bisher nicht verfolgt haben, gehen wir von folgenden Annahmen aus:

• Sie haben Django Version 4 oder höher installiert.
• Sie haben Ihre Django-Anwendung mit einer Datenbank verbunden.
• Sie arbeiten mit einem Unix-basierten Betriebssystem, vorzugsweise einem Ubuntu 22.04 Cloud-Server, da wir mit diesem System getestet haben.

Da sich dieses Tutorial hauptsächlich mit Django-Modellen befasst, können Sie ihm möglicherweise auch dann folgen, wenn Sie eine andere Konfiguration verwenden.

Schritt 1 – Erstellen Sie die Django-Anwendung

Um der modularen Philosophie von Django gerecht zu werden, erstellen wir in unserem Projekt eine Django-Anwendung, die alle Dateien enthält, die zum Erstellen der Blog-Website erforderlich sind.

Sobald wir mit Python und Django arbeiten, müssen wir unsere virtuelle Python-Umgebung aktivieren und sie in das Stammverzeichnis unserer Anwendung verschieben. Wenn Sie der Artikelserie gefolgt sind, können Sie dies mit folgendem Befehl erreichen.

cd ~/my_blog_app
. env/bin/activate
cd blogr code... */

Führen wir nun folgenden Befehl aus:

python manage.py startapp blogsite

Dieses Programm erstellt unsere Blogseite sowie ein Verzeichnis.

An diesem Punkt der Tutorialreihe verfügt Ihr Projekt über folgende Verzeichnisstruktur:

my_blog_app/
└── blog
├── blog
│ ├── __init__.py
│ ├── __pycache__
│ │ ├── __init__.cpython-38.pyc
│ │ ├── settings.cpython-38.pyc
│ │ ├── urls.cpython-38.pyc
│ │ └── wsgi.cpython-38.pyc
│ ├── asgi.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── blogsite
│ ├── __init__.py
│ ├── admin.py
│ ├── apps.py
│ ├── migrations
│ │ └── __init__.py
│ ├── models.py
│ ├── tests.py
│ └── views.py
└── manage.py

Die Datei, auf die wir uns in diesem Tutorial konzentrieren werden, ist die Datei models.py, die sich im Blog-Verzeichnis der Website befindet.

Schritt 2 – Beitragsvorlagen hinzufügen

Zuerst müssen wir die Datei models.py öffnen und bearbeiten, um den Code zum Generieren eines Post-Modells einzufügen. Ein Post-Modell enthält die folgenden Datenbankfelder:

• TITEL – Der Titel des Blogbeitrags.
• Slug – Hier werden gültige URLs für Webseiten gespeichert und generiert.
• INHALT – Der Textinhalt des Blogbeitrags.
• create_on – Das Datum, an dem der Beitrag erstellt wurde.
• AUTOR – Die Person, die den Beitrag verfasst hat.

Wechseln Sie nun in das Verzeichnis, in dem sich die Datei models.py befindet.

cd ~/my_blog_app/blog/blogsite

Verwenden Sie den Befehl cat, um den Inhalt der Datei in Ihrem Terminal anzuzeigen.

cat models.py

Die Datei sollte den folgenden Code enthalten, der die Modelle importiert, sowie einen Kommentar, der erklärt, was in diese models.py-Datei gehört.

from django.db import models
# Create your models here.

Fügen Sie mit Ihrem bevorzugten Texteditor den folgenden Code in die Datei models.py ein. Wir verwenden hier nano als Texteditor, Sie können aber jeden beliebigen Editor verwenden.

nano models.py

In dieser Datei ist der Code zum Importieren der API-Modelle bereits enthalten, daher können wir den unten stehenden Kommentar entfernen. Anschließend importieren wir `slugify`, um Slugs aus Strings zu generieren, den Django-Benutzer zur Authentifizierung und umgekehrt `django.urls`, um mehr Flexibilität bei der URL-Erstellung zu erhalten.

from django.db import models
from django.template.defaultfilters import slugify
from django.contrib.auth.models import User
from django.urls import reverse

Fügen Sie als Nächstes in der Modellklasse „Post“ eine Klassenmethode mit den folgenden Datenbankfeldern hinzu: title, slug, content, created_on und author. Fügen Sie diese unterhalb Ihrer Importanweisungen ein.

...
class Post(models.Model):
title = models.CharField(max_length=255)
slug = models.SlugField(unique=True, max_length=255)
content = models.TextField()
created_on = models.DateTimeField(auto_now_add=True)
author = models.TextField()

Als Nächstes fügen wir eine Funktion zum Generieren der URL und eine Funktion zum Speichern des Beitrags hinzu. Dies ist sehr wichtig, da dadurch ein eindeutiger Link für unseren jeweiligen Beitrag erstellt wird.

...
def get_absolute_url(self):
return reverse('blog_post_detail', args=[self.slug])

def save(self, *args, **kwargs):
if not self.slug:
self.slug = slugify(self.title)
super(Post, self).save(*args, **kwargs)

Nun müssen wir dem Modell mitteilen, wie die Beiträge sortiert und auf der Webseite angezeigt werden sollen. Die entsprechende Logik wird in einer verschachtelten Metaklasse implementiert. Diese Metaklasse enthält in der Regel weitere wichtige Modelllogik, die nicht mit der Definition der Datenbankfelder zusammenhängt.

...
class Meta:
ordering = ['created_on']

def __unicode__(self):
return self.title

Abschließend fügen wir das Comment-Modell zu dieser Datei hinzu. Dazu erstellen wir eine weitere Klasse namens Comment mit models.Models in ihrer Signatur und definieren die folgenden Datenbankfelder:

• NAME – Der Name der Person, die den Kommentar abgibt.
• E-MAIL – Die E-Mail-Adresse der Person, die den Kommentar abgibt.
• TEXT – Der Text des Kommentars selbst.
• BEITRAG – Der Beitrag, zu dem der Kommentar verfasst wurde.
• create_on – Wann der Kommentar erstellt wurde.

...
class Comment(models.Model):
name = models.CharField(max_length=42)
email = models.EmailField(max_length=75)
website = models.URLField(max_length=200, null=True, blank=True)
content = models.TextField()
post = models.ForeignKey(Post, on_delete=models.CASCADE)
created_on = models.DateTimeField(auto_now_add=True)

An diesem Punkt ist models.py vollständig. Stellen Sie sicher, dass Ihre models.py-Datei dem Folgenden entspricht:

from django.db import models
from django.template.defaultfilters import slugify
from django.contrib.auth.models import User
from django.urls import reverse


class Post(models.Model):
title = models.CharField(max_length=255)
slug = models.SlugField(unique=True, max_length=255)
content = models.TextField()
created_on = models.DateTimeField(auto_now_add=True)
author = models.TextField()

def get_absolute_url(self):
return reverse('blog_post_detail', args=[self.slug])

def save(self, *args, **kwargs):
if not self.slug:
self.slug = slugify(self.title)
super(Post, self).save(*args, **kwargs)

class Meta:
ordering = ['created_on']

def __unicode__(self):
return self.title


class Comment(models.Model):
name = models.CharField(max_length=42)
email = models.EmailField(max_length=75)
website = models.URLField(max_length=200, null=True, blank=True)
content = models.TextField()
post = models.ForeignKey(Post, on_delete=models.CASCADE)
created_on = models.DateTimeField(auto_now_add=True)

Vergessen Sie nicht, die Datei zu speichern und zu schließen. Wenn Sie nano verwenden, können Sie dies tun, indem Sie STRG und X, dann Y und anschließend die Eingabetaste drücken.

Wenn die models.py-Datei ausgeführt wird, können wir unsere settings.py-Datei aktualisieren.

Schritt 3 – Einstellungen aktualisieren

Nachdem wir unserer Anwendung Modelle hinzugefügt haben, müssen wir unser Projekt über die Existenz der soeben hinzugefügten Blog-Anwendung informieren. Dies geschieht durch Hinzufügen zur Sektion INSTALLED_APPS in der Datei settings.py.

Wechseln Sie in das Verzeichnis, in dem sich Ihre settings.py-Datei befindet.

cd ~/my_blog_app/blog/blog

Öffnen Sie von hier aus beispielsweise Ihre settings.py-Datei mit nano.

nano settings.py

Öffnen Sie die Datei und fügen Sie die Blog-App Ihrer Website dem Abschnitt INSTALLED_APPS der Datei hinzu, wie unten gezeigt.

# Application definition
INSTALLED_APPS = [
'blogsite',
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
]

Nachdem die Blog-Anwendung der Website hinzugefügt wurde, können Sie die Datei speichern und das Programm beenden.

An diesem Punkt sind wir bereit, mit der Umsetzung dieser Änderungen fortzufahren.

Schritt 4 – Migration durchführen

Nachdem die Modelle für Beiträge und Kommentare hinzugefügt wurden, besteht der nächste Schritt darin, diese Änderungen anzuwenden, damit unser MySQL-Datenbankschema sie erkennt und die notwendigen Tabellen erstellt.

Zuerst müssen wir unsere Modelländerungen mithilfe des Befehls `makemigrations` in separate Migrationsdateien packen. Diese Dateien ähneln Commits in einem Versionskontrollsystem wie Git.

Wenn Sie nun zu ~/my_blog_app/blog/blogsite/migrations navigieren und den Befehl `ls` ausführen, werden Sie feststellen, dass dort nur eine __init__.py-Datei vorhanden ist. Dies ändert sich, sobald wir Migrationen hinzufügen.

Wechseln Sie mit dem Befehl `cd` in das Blog-Verzeichnis, etwa so:

cd ~/my_blog_app/blog

Führen Sie anschließend den Befehl makemigrations in manager.py aus.

python manage.py makemigrations

Anschließend sollte in Ihrem Terminalfenster folgende Ausgabe erscheinen:

Output
Migrations for 'blogsite':
blogsite/migrations/0001_initial.py
- Create model Post
- Create model Comment

Erinnern Sie sich, als wir zu /~/my_blog_app/blog/blogsite/migrations navigierten und dort nur die Datei __init__.py gefunden haben? Wenn wir jetzt zu diesem Verzeichnis zurückkehren, sehen wir, dass zwei weitere Dateien hinzugefügt wurden: __pycache__ und 0001_initial.py. Die Datei 0001_initial.py wurde automatisch beim Ausführen von makemigrations erstellt. Eine ähnliche Datei wird jedes Mal erstellt, wenn Sie makemigrations ausführen.

Wenn Sie den Inhalt der Datei lesen möchten, führen Sie einfach 0001_initial.py aus dem Verzeichnis aus, in dem sie sich befindet.

Gehe nun zu ~/my_blog_app/blog:

cd ~/my_blog_app/blog

Da wir eine Migrationsdatei erstellt haben, müssen wir die darin beschriebenen Änderungen mithilfe des Befehls `migrate` auf die Datenbank anwenden. Zuvor überprüfen wir jedoch mit dem Befehl `showmigrations`, welche Migrationen aktuell vorhanden sind.

python manage.py showmigrations

Output
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
[X] 0010_alter_group_name_max_length
[X] 0011_update_proxy_permissions
blogsite
[ ] 0001_initial
contenttypes
[X] 0001_initial
[X] 0002_remove_content_type_name
sessions
[X] 0001_initial

Sie werden feststellen, dass alle Migrationen überprüft wurden, mit Ausnahme derjenigen für 0001_initial, die wir mit den Modellen Post und Comment erstellt haben.

Nun überprüfen wir mit dem folgenden Befehl, welche SQL-Anweisungen nach Abschluss der Migrationen ausgeführt werden. Er benötigt die Migration und den Migrationstitel als Argumente:

python manage.py sqlmigrate blogsite 0001_initial

Nachfolgend wird die tatsächliche SQL-Abfrage angezeigt, die im Hintergrund ausgeführt wird.

Output
--
-- Create model Post
--
CREATE TABLE `blogsite_post` (`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, `title` varchar(255) NOT NULL, `slug` varchar(255) NOT NULL UNIQUE, `content` longtext NOT NULL, `created_on` datetime(6) NOT NULL, `author` longtext NOT NULL);
--
-- Create model Comment
--
CREATE TABLE `blogsite_comment` (`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, `name` varchar(42) NOT NULL, `email` varchar(75) NOT NULL, `website` varchar(200) NULL, `content` longtext NOT NULL, `created_on` datetime(6) NOT NULL, `post_id` integer NOT NULL);
ALTER TABLE `blogsite_comment` ADD CONSTRAINT `blogsite_comment_post_id_de248bfe_fk_blogsite_post_id` FOREIGN KEY (`post_id`) REFERENCES `blogsite_post` (`id`);

Jetzt führen wir die Migrationen aus, um sie auf unsere MySQL-Datenbank anzuwenden.

python manage.py migrate

Wir erhalten folgende Ausgabe:

Output
Operations to perform:
Apply all migrations: admin, auth, blogsite, contenttypes, sessions
Running migrations:
Applying blogsite.0001_initial... OK

Ihre Migrationen wurden nun erfolgreich angewendet.

Wichtig ist, sich daran zu erinnern, dass es, wie in der Django-Dokumentation angegeben, drei Einschränkungen bei der Migration von Django mit MySQL als Backend gibt.

• Transaktionen im Zusammenhang mit Schemaänderungen werden nicht unterstützt. Das heißt, wenn eine Migration fehlschlägt, müssen Sie die vorgenommenen Änderungen manuell auswählen, um eine neue Migration durchzuführen. Es gibt keine Möglichkeit, zu einem vorherigen Zeitpunkt zurückzukehren, bevor Änderungen an der fehlgeschlagenen Migration vorgenommen wurden.
• Bei den meisten Schemaänderungen schreibt MySQL die Tabellen komplett neu. Im ungünstigsten Fall ist die Zeitkomplexität proportional zur Anzahl der Zeilen in der Tabelle, in der Spalten hinzugefügt oder entfernt werden sollen. Laut Django-Dokumentation kann dies bis zu einer Minute pro Million Zeilen dauern.
• In MySQL gibt es geringe Längenbeschränkungen für Spalten-, Tabellen- und Indexnamen. Auch die Gesamtgröße aller Spalten und Indizes ist begrenzt. Während einige andere Backends die in Django festgelegten höheren Beschränkungen unterstützen, lassen sich dieselben Indizes mit einem MySQL-Backend nicht erstellen.

Bei jeder Datenbank, die Sie für die Verwendung mit Django in Betracht ziehen, sollten Sie unbedingt die Vor- und Nachteile jeder einzelnen abwägen.

Schritt 5 – Datenbankschema überprüfen

Nach Abschluss der Migration müssen wir die erfolgreiche Generierung der MySQL-Tabellen überprüfen, die wir mithilfe der Django-Modelle erstellt haben.

Um dies zu tun, führen Sie folgenden Befehl im Terminal aus, um sich bei MySQL anzumelden.

mysql blog_data -u djangouser

Wählen Sie nun unsere Datenbank „blog_data“ aus. Falls Sie nicht wissen, welche Datenbank Sie verwenden, können Sie alle Datenbanken mit dem Befehl „SHOW DATABASES“ anzeigen lassen. (In SQL)

USE blog_data;

Geben Sie anschließend den folgenden Befehl ein, um die Tabellen anzuzeigen.

SHOW TABLES;

Diese SQL-Abfrage sollte Folgendes ergeben:

Output
+----------------------------+
| Tables_in_blog_data |
+----------------------------+
| auth_group |
| auth_group_permissions |
| auth_permission |
| auth_user |
| auth_user_groups |
| auth_user_user_permissions |
| blogsite_comment |
| blogsite_post |
| django_admin_log |
| django_content_type |
| django_migrations |
| django_session |
+----------------------------+
12 rows in set (0.01 sec)

Die Tabellen umfassen blogsite_comment und blogsite_post. Dies sind von uns selbst erstellte Modelle. Überprüfen wir, ob sie die von uns definierten Felder enthalten.

DESCRIBE blogsite_comment;

Output
+------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+--------------+------+-----+---------+----------------+
| id | int | NO | PRI | NULL | auto_increment |
| name | varchar(42) | NO | | NULL | |
| email | varchar(75) | NO | | NULL | |
| website | varchar(200) | YES | | NULL | |
| content | longtext | NO | | NULL | |
| created_on | datetime(6) | NO | | NULL | |
| post_id | int | NO | MUL | NULL | |
+------------+--------------+------+-----+---------+----------------+
7 rows in set (0.00 sec)

DESCRIBE blogsite_post;

Output
+------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+--------------+------+-----+---------+----------------+
| id | int | NO | PRI | NULL | auto_increment |
| title | varchar(255) | NO | | NULL | |
| slug | varchar(255) | NO | UNI | NULL | |
| content | longtext | NO | | NULL | |
| created_on | datetime(6) | NO | | NULL | |
| author | longtext | NO | | NULL | |
+------------+--------------+------+-----+---------+----------------+
6 rows in set (0.00 sec)

Wir haben überprüft, dass die Datenbanktabellen erfolgreich aus unseren Django-Modellmigrationen generiert wurden.

Sie können MySQL mit STRG + D schließen und wenn Sie Ihre Python-Umgebung verlassen möchten, können Sie den Befehl disable ausführen:

deactivate

Durch Deaktivieren der Entwicklungsumgebung gelangen Sie zurück zur Terminal-Befehlszeile.

Ergebnis

In diesem Tutorial haben wir erfolgreich Modelle für grundlegende Funktionen in einer Blog-Webanwendung hinzugefügt. Sie haben gelernt, wie man die Modelle programmiert, wie Migrationen funktionieren und wie man Django-Modelle in echte MySQL-Datenbanktabellen übersetzt.