TL;DR Fortsetzung von Amateur-Infrastrukturingenieur berührt Django mit Docker-Serie ①: Django mit Docker erstellen. Ich werde ein Modell für Django erstellen, das ich das letzte Mal gemacht habe. Es gibt eine Seite namens Django Girls, die ein Django-Tutorial enthält. Dieses Mal werde ich den Blog gemäß den Kapiteln nach dem "Django-Modell" testen. Spielen Sie mit Django, während Sie versuchen, es zu erstellen. (Diese Seite ist sehr einfach zu verstehen, und ehrlich gesagt ist es vielleicht besser, als sich diesen Beitrag anzusehen, aber indem man den Lernprozess und die Forschung offenlegt, wenn ein Amateur sie berührt, sind Menschen auf dem gleichen Niveau Ich schreibe mit dem Ziel, das Verständnis zu fördern.)
Model - Template - View Django scheint mit der Idee von MTV (Model Template View) entworfen worden zu sein. Ich habe von MVC (Model View Controller) gehört (nur der Name). .. Überprüfen Sie eins nach dem anderen.
Model Das Modell interagiert mit der Datenbank. Im Blog-Beispiel von DjangoGirls werden nach Erwähnung der Objektorientierung die folgenden Daten als notwendige Daten für das Blog aufgeführt.
Post
--------
title
text
author
created_date
published_date
Ein solches Datenformat, das benötigt wird, wird als Modell definiert, und wenn eine Anforderung eingeht, werden die erforderlichen Daten aus der Datenbank abgerufen und zurückgegeben. Dies scheint ungefähr der Rolle des Modells in MVC zu entsprechen. (Vielleicht)
Template Vorlagen in Django beziehen sich auf den gut aussehenden Teil. Dies beinhaltet HTML und CSS sowie Javascript als Ergänzung. In MVC die Rolle von View. Es ist kompliziert. .. In MVC erhält Controller keine Daten direkt von Model in MTV, genau wie Controller Bridges Model und View. Stellen Sie sicher, dass Sie Daten über View verarbeiten.
View Wie ich in der Vorlage ein wenig erwähnt habe, beschreibt View, wie die mit Model erfassten Informationen angezeigt werden. Danach wird es zu einer Funktion gemacht und mit der Vorlage verknüpft. Mit anderen Worten, als Rolle, ① Geben Sie einen Datenerfassungsbefehl an Model aus ② Bestimmen Sie die Vorlage, die an die Benutzeranforderung zurückgegeben werden soll ③ Übergeben Sie die vom Modell erfassten Daten als Funktion an die Vorlage Dort sind drei. (Ich bin nicht sehr zuversichtlich, aber wenn ich einen Fehler mache, werde ich ihn beheben. Bitte weisen Sie darauf hin.) Wenn ein Benutzer eine Website aus Django besucht, entscheiden Sie zunächst, welche Ansichtsfunktion gemäß der Beschreibung in urls.py verarbeitet werden soll. Die ausgewählte Ansichtsfunktion verwendet Modell, um Daten zu erfassen und als ausgewählte Vorlage zu verwenden. Zeigen Sie die Webseite nach Übergabe der Daten an.
Ist das Bild irgendwie wie folgt? U ⇒ urls.py ⇒ view.py ⇔ Model ⇔ DB S ⇓ E ⇓ R ⇐ Templates
Fahren Sie mit einem weichen Bewusstsein für diese drei Rollen mit dem Bau fort.
manage.py startapp
docker-compose run web python manage.py startapp blog
Erstellen Sie eine Anwendungsvorlage in der lokalen Umgebung mit der zuvor erstellten Datei docker-compose.yaml. Beim letzten Mal wurde manage.py für den Ausführungsserver verwendet, um den Webserver zu starten. Wenn Sie jedoch die Start-App verwenden, werden die zum Erstellen des Modells erforderlichen Dateien erstellt. Die Verzeichnisstruktur nach Ausführung dieses Befehls, einschließlich der vorherigen Ausführung, sollte wie folgt aussehen.
.
∟ blog
∟ admin.py
∟ apps.py
∟ __init__.py
∟ migrations
∟ models.py
∟ tests.py
∟ views.py
∟ composeexample
∟ __init__.py
∟ __pycache__
∟ settings.py
∟ urls.py
∟ wsgi.py
∟ docker-compose.yaml
∟ Dockerfile
∟ manage.py
∟ migrations
∟ requirements.txt
Wenn Sie es wie zuvor auf einem Linux-Computer ausführen, sind die Ordnerberechtigungen root. Gehen Sie wie folgt vor:
sudo chown -R $USER:$USER .
settings.py
settings.py
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'blog',
]
Fügen Sie die diesmal erstellte Anwendung zu INSTALLED_APPS hinzu.
models.py
blog/models.py
from django.conf import settings
from django.db import models
from django.utils import timezone
class Post(models.Model):
author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
title = models.CharField(max_length=200)
text = models.TextField()
created_date = models.DateTimeField(default=timezone.now)
published_date = models.DateTimeField(blank=True, null=True)
def publish(self):
self.published_date = timezone.now()
self.save()
def __str__(self):
return self.title
Erstellen Sie eine Modelldefinition. In dem von startapp erstellten Blog-Ordner befindet sich models.py. Bearbeiten Sie ihn daher. Von Anfang an wird nur die zweite Zeile "aus django.db-Importmodellen" ausgeliehen, und das Django Girls-Beispiel wird ausgeliehen.
from django.conf import settings
Ein Modul, mit dem auf die Variablen in project / settings.py verwiesen wird.
from django.db import models
Ein Modul, das verschiedene Methoden in Bezug auf das Modell bereitstellt. Externe Schlüssel, Datentypen usw.
from django.utils import timezone
Modul bezogen auf die Zeitzone. Es ist fast das gleiche wie das Dienstprogramm, das in verschiedenen Sprachen bereitgestellt wird. Dieses Mal verwende ich es, um die Zeit zum Zeitpunkt der Veröffentlichung zu ermitteln. Da die Zeitzone in settings.py festgelegt ist, sollte sie in der aktuellen Situation, in der nichts unternommen wird, UTC sein.
class Post(models.Model):
Der Teil, der das Modell definiert, heißt Post. Das zu definierende Modell wird durch Erben von django.db.models.Model erstellt. Es ist auch möglich, untergeordnete Klassen zu erstellen. Beispielsweise kann create_date in anderen Modellen für allgemeine Zwecke verwendet werden. Erstellen Sie daher eine Timestamp-Klasse, die create_date-Daten definiert, und erben Sie diese in Form von Post (Timestamp).
author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
ForeignKey () definiert ein Modell, das ein Fremdschlüssel ist. Dieses Mal wird die MODELL-Definition mithilfe des Einstellungsmoduls erfasst, um das Benutzermodell anzugeben, das Django standardmäßig als externen Schlüssel hat. Wenn Sie jedoch normalerweise das Modell verwenden, das Sie als externer Schlüssel erstellt haben, das Modell Geben Sie den Namen an. Die Option on_delete ist in Django 2.0 oder höher erforderlich und gibt das Verhalten beim Löschen eines Objekts mit einem externen Schlüssel an. CASCADE löscht alle zugeordneten Objekte, wenn ein Objekt mit einem externen Schlüssel gelöscht wird.
title = models.CharField(max_length=200)
text = models.TextField()
created_date = models.DateTimeField(default=timezone.now)
published_date = models.DateTimeField(blank=True, null=True)
Geben Sie die Datentypen und Einschränkungen an, aus denen das Blog besteht. Für created_date wird die Zeit eingegeben, zu der das Objekt erstellt wurde. Das heißt, die Zeit, als der Artikel geschrieben wurde. Andererseits ist das veröffentlichte_Datum momentan leer und der Wert wird in die später beschriebene Veröffentlichungsmethode eingegeben.
def publish(self):
self.published_date = timezone.now()
self.save()
Eine Methode zum Veröffentlichen von Blog-Artikeln. Die aktuelle Zeit wird dem Veröffentlichungsdatum zugewiesen, dh der veröffentlichten Zeit, und die Methode save () wird aufgerufen. Ich kann mich nicht erinnern, die save () -Methode geschrieben zu haben, also natürlich in die Methode in den Vererbungsquellmodellen. Modell: Wenn der Primärschlüssel in der Tabelle vorhanden ist, aktualisieren Sie ihn und wenn er nicht vorhanden ist, erstellen Sie ihn.
def __str__(self):
return self.title
magische Methode. (Da dies nicht der Hauptpunkt der magischen Methode ist, überprüfen Sie sie bitte selbst.) Der Titel des Blog-Artikels wird zurückgegeben, wenn er instanziiert wird.
In Django scheint das Erstellen einer Tabelle in der Datenbank, die mit dem Inhalt von models.py verbunden ist, als Migration bezeichnet zu werden. Wenn Sie den Befehl "manage.py makemigrations" ausführen, wird eine Datei für die Migration erstellt, und der Befehl "manage.py migrate" erstellt tatsächlich eine Tabelle in der Datenbank. Geben Sie den Webserver sofort mit "Docker-Compose Exec" ein, führen Sie den Befehl aus, geben Sie den Datenbankserver ein und prüfen Sie, ob die Tabelle erstellt wurde. (Diese Operationen werden dem Befehl in Docker-Compose später hinzugefügt, damit die Migration mit "Docker-Compose Up" durchgeführt wird. Jetzt gebe ich den Container ein und führe den Befehl zur Bestätigung aus.)
docker-compose exec web bash
(Im Folgenden im Webcontainer)
manage.py makemigrations blog
Die folgende Ausgabe wird ausgegeben. blog/migrations/0001_initial.py
manaeg.py migrate blog
Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying blog.0001_initial... OK Wenn die Ausgabe wie oben ist, ist die Migration abgeschlossen. Beenden Sie den Webserver mit exit und geben Sie den zu überprüfenden Datenbankserver ein.
docker-compose exec db bash
(Nachfolgend im DB-Container)
psql -U postgres
\d
\d Ausführungsergebnis
List of relations
Schema | Name | Type | Owner
--------+-----------------------------------+----------+----------
public | auth_group | table | postgres
public | auth_group_id_seq | sequence | postgres
public | auth_group_permissions | table | postgres
public | auth_group_permissions_id_seq | sequence | postgres
public | auth_permission | table | postgres
public | auth_permission_id_seq | sequence | postgres
public | auth_user | table | postgres
public | auth_user_groups | table | postgres
public | auth_user_groups_id_seq | sequence | postgres
public | auth_user_id_seq | sequence | postgres
public | auth_user_user_permissions | table | postgres
public | auth_user_user_permissions_id_seq | sequence | postgres
public | blog_post | table | postgres
public | blog_post_id_seq | sequence | postgres
public | django_content_type | table | postgres
public | django_content_type_id_seq | sequence | postgres
public | django_migrations | table | postgres
public | django_migrations_id_seq | sequence | postgres
Es gibt viele Tabellen. auth und django werden wahrscheinlich standardmäßig (wahrscheinlich) erstellt. Da ich blog_post in models.py geschrieben habe, überprüfen Sie die Definition der blog_post-Tabelle.
\d blog_post
\d Ausführungsergebnis
Table "public.blog_post"
Column | Type | Collation | Nullable | Default
----------------+--------------------------+-----------+----------+---------------------------------------
id | integer | | not null | nextval('blog_post_id_seq'::regclass)
title | character varying(200) | | not null |
text | text | | not null |
created_date | timestamp with time zone | | not null |
published_date | timestamp with time zone | | |
author_id | integer | | not null |
Indexes:
"blog_post_pkey" PRIMARY KEY, btree (id)
"blog_post_author_id_dd7a8485" btree (author_id)
Foreign-key constraints:
"blog_post_author_id_dd7a8485_fk_auth_user_id" FOREIGN KEY (author_id) REFERENCES auth_user(id) DEFERRABLE INITIALLY DEFERRED
id ist eine Seriennummer, die standardmäßig angegeben wird, wenn django ein Modell definiert, und der Primärschlüssel ist. Andere sind wie in models.py definiert. Das Modell ist jetzt fertig.
Es fühlt sich endlich wie der zweite Schritt an, aber machen wir es unbedingt. ..
Recommended Posts