TL;DR Poursuite de L'ingénieur d'infrastructure amateur touche Django avec la série Docker ①: Créer Django avec Docker. Je vais créer un modèle pour django que j'ai fait la dernière fois. Il existe un site appelé Django Girls qui a un tutoriel django, donc cette fois je vais échantillonner le blog selon les chapitres après "Django model" de celui-ci. Jouez avec django en essayant de le créer. (Ce site est très facile à comprendre, et honnêtement, cela peut être mieux que de regarder ce post, mais en divulguant le processus d'apprentissage et de recherche lorsqu'un amateur l'a touché, des personnes du même niveau J'écris dans le but de promouvoir la compréhension.)
Model - Template - View Django semble être conçu avec l'idée de MTV (Model Template View). J'ai entendu parler de MVC (Model View Controller) (seulement le nom). .. Vérifiez un par un.
Model Le modèle interagit avec la base de données. Dans l'exemple de blog DjangoGirls, après avoir mentionné l'orientation des objets, les éléments suivants sont répertoriés comme données nécessaires pour le blog.
Post
--------
title
text
author
created_date
published_date
Un tel format de données qui sera nécessaire est défini comme un modèle, et lorsqu'une demande arrive, les données nécessaires sont extraites de la base de données et renvoyées. Cela semble être à peu près le même que le rôle de Model dans MVC. (Peut-être)
Template Les modèles dans Django font référence à la bonne partie. Cela inclut html et CSS et javascript pour le compléter. Dans MVC, le rôle de View. C'est compliqué. .. Dans MVC, le contrôleur relie le modèle et la vue, et le modèle dans le MTV n'obtient pas de données directement du modèle. Assurez-vous de gérer les données via View.
View Comme je l'ai mentionné un peu dans Template, View décrit comment afficher les informations acquises à l'aide de Model. Après cela, il est transformé en fonction et lié à Template. En d'autres termes, en tant que rôle, ① Émettez une commande d'acquisition de données au modèle ② Déterminer le modèle à renvoyer à la demande de l'utilisateur ③ Passer les données acquises du modèle au modèle en tant que fonction Il ya trois. (Je ne suis pas très confiant, mais si je fais une erreur, je vais la réparer, alors veuillez le signaler.) Lorsqu'un utilisateur visite un site Web fait de django, décidez d'abord quelle fonction View traiter en fonction de la description dans urls.py, et la fonction View sélectionnée utilise Model pour acquérir des données et les utiliser comme modèle sélectionné. Affichez la page Web après avoir transmis les données.
L'image est-elle en quelque sorte la suivante? U ⇒ urls.py ⇒ view.py ⇔ Model ⇔ DB S ⇓ E ⇓ R ⇐ Templates
Avec une douce conscience de ces trois rôles, passez à la construction.
manage.py startapp
docker-compose run web python manage.py startapp blog
Créez un modèle d'application dans l'environnement local à l'aide du fichier docker-compose.yaml créé précédemment. La dernière fois, manage.py a été utilisé pour que le serveur d'exécution démarre le serveur Web, mais si vous utilisez l'application de démarrage, il créera les fichiers nécessaires pour créer le modèle. La structure du répertoire après l'exécution de cette commande, y compris l'exécution précédente, doit être la suivante.
.
∟ 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
Comme auparavant, si vous l'exécutez sur une machine Linux, les autorisations de dossier seront root, alors procédez comme suit:
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',
]
Ajoutez l'application créée cette fois à INSTALLED_APPS.
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
Créez une définition de modèle. Il y a models.py dans le dossier du blog créé par startapp, alors modifiez-le. Depuis le début, seule la deuxième ligne, from django.db import models, est empruntée, et l'exemple Django Girls est emprunté.
from django.conf import settings
Un module utilisé pour faire référence aux variables dans project / settings.py.
from django.db import models
Un module qui fournit diverses méthodes liées au modèle. Clés externes, types de données, etc.
from django.utils import timezone
Module lié au fuseau horaire. C'est presque le même que l'utilitaire fourni dans différentes langues. Cette fois, je l'utilise pour obtenir l'heure au moment de la publication. Puisque le fuseau horaire est défini dans settings.py, il devrait être UTC dans la situation actuelle où rien n'est fait.
class Post(models.Model):
La partie qui définit le modèle appelé Post. Le modèle à définir est créé en héritant de django.db.models.Model. Il est également possible de créer des classes enfants. Par exemple, create_date peut être utilisé dans d'autres modèles à des fins générales, créez donc une classe Timestamp qui définit les données create_date et héritez-en sous la forme Post (Timestamp).
author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
ForeignKey () définit un modèle qui est une clé étrangère. Cette fois, afin de spécifier le modèle User que django a par défaut comme clé externe, la définition MODEL est acquise à l'aide du module de paramètres, mais si vous utilisez normalement le modèle que vous avez créé comme clé externe, le modèle Précisez le nom. L'option on_delete est requise dans django 2.0 ou version ultérieure et spécifie le comportement lors de la suppression d'un objet avec une clé externe. CASCADE supprime tous les objets associés lors de la suppression d'un objet avec une clé externe.
title = models.CharField(max_length=200)
text = models.TextField()
created_date = models.DateTimeField(default=timezone.now)
published_date = models.DateTimeField(blank=True, null=True)
Spécifiez les types de données et les contraintes qui composent le blog. Pour created_date, l'heure à laquelle l'objet a été créé est entrée. Autrement dit, le moment où l'article a été écrit. En revanche, Published_date est vide pour le moment et la valeur est entrée dans la méthode de publication décrite plus loin.
def publish(self):
self.published_date = timezone.now()
self.save()
Une méthode pour publier des articles de blog. L'heure actuelle est affectée à published_date, qui est l'heure de publication, et la méthode save () est appelée. Je ne me souviens pas avoir écrit la méthode save (), donc bien sûr, dans la méthode dans les modèles source d'héritage.Modèle, si la clé primaire existe dans la table, METTEZ-LA À JOUR et si elle n'existe pas, CRÉER
def __str__(self):
return self.title
méthode magique. (Comme ce n'est pas le point principal de la méthode magique, veuillez le vérifier vous-même.) Le titre de l'article du blog est renvoyé lorsqu'il est instancié.
Dans django, la création d'une table dans la base de données connectée au contenu de models.py semble s'appeler migration.
Lorsque vous exécutez la commande manage.py makemigrations, un fichier de migration est créé et la commande manage.py migrate crée en fait une table sur la base de données.
Entrez immédiatement le serveur Web avec docker-compose exec, exécutez la commande, entrez le serveur de base de données et vérifiez si la table est créée. (Ces opérations seront ajoutées à la commande dans docker-compose plus tard afin que la migration soit effectuée avec docker-compose up, mais maintenant j'entre dans le conteneur et j'exécute la commande pour confirmation)
docker-compose exec web bash
(Ci-après dans le conteneur Web)
manage.py makemigrations blog
La sortie suivante est sortie. blog/migrations/0001_initial.py
manaeg.py migrate blog
Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying blog.0001_initial... OK Si la sortie est comme ci-dessus, la migration est terminée. Quittez le serveur Web avec exit et entrez dans le serveur de base de données pour vérifier.
docker-compose exec db bash
(Ci-après dans le conteneur db)
psql -U postgres
\d
\d Résultat de l'exécution
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
Il existe de nombreuses tables. auth et django sont probablement créés par défaut (probablement). Depuis que j'ai écrit blog_post dans models.py, vérifiez la définition de la table blog_post.
\d blog_post
\d Résultat de l'exécution
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 est un numéro de série donné par défaut lorsque django définit un modèle, et est la clé primaire. D'autres sont tels que définis dans models.py. Le modèle est maintenant prêt.
Cela ressemble enfin à la deuxième étape, mais faisons-le sans faute. ..
Recommended Posts