Configurer la base de données

Introduction

Ce tutoriel reprend là où Création d'une application de sondage de base s'est arrêté. Nous allons configurer la base de données, créer votre premier modèle et obtenir une brève introduction au site d'administration automatiquement généré par Django.

Configuration de la base de données

Maintenant, ouvrez mysite/settings.py. C'est un module Python normal avec des variables de niveau de module représentant les paramètres de Django.

Par défaut, la configuration utilise SQLite. Si vous êtes nouveau dans le domaine des bases de données, ou si vous êtes simplement intéressé par l'essai de Django, c'est le choix le plus simple. SQLite est inclus dans Python, donc vous n'aurez pas besoin d'installer autre chose pour prendre en charge votre base de données. Cependant, lorsqu'il s'agit de démarrer votre premier projet réel, vous souhaiterez peut-être utiliser une base de données plus scalable comme PostgreSQL, pour éviter les problèmes de changement de base de données plus tard.

Si vous souhaitez utiliser une autre base de données, installez les liaisons de base de données appropriées <installation-de-base-de-donnees> et modifiez les clés suivantes dans l'élément 'default' de DATABASES pour correspondre à vos paramètres de connexion à la base de données :

• ENGINE <MOTEUR-DE-BASE-DE-DONNEES> -- Soit 'django.db.backends.sqlite3', 'django.db.backends.postgresql', 'django.db.backends.mysql', ou 'django.db.backends.oracle'. D'autres backends sont également disponibles <notes-sur-les-tiers>.
• NAME -- Le nom de votre base de données. Si vous utilisez SQLite, la base de données sera un fichier sur votre ordinateur ; dans ce cas, NAME devrait être le chemin absolu complet, y compris le nom de fichier, de ce fichier. La valeur par défaut, BASE_DIR / 'db.sqlite3', stockera le fichier dans votre répertoire de projet.

Si vous n'utilisez pas SQLite comme base de données, des paramètres supplémentaires tels que USER, PASSWORD et HOST doivent être ajoutés. Pour plus de détails, consultez la documentation de référence pour DATABASES.

Pour les bases de données autres que SQLite

Si vous utilisez une base de données autre que SQLite, assurez-vous d'avoir créé une base de données à ce stade. Faites-le avec "CREATE DATABASE database_name;" dans l'invite interactive de votre base de données.

Vérifiez également que l'utilisateur de base de données fourni dans mysite/settings.py a les privilèges "créer une base de données". Cela permet la création automatique d'une base de données de test <la-base-de-donnees-de-test> qui sera nécessaire dans un tutoriel ultérieur.

Si vous utilisez SQLite, vous n'avez pas besoin de créer quoi que ce soit à l'avance - le fichier de base de données sera créé automatiquement lorsqu'il est nécessaire.

Pendant que vous éditez mysite/settings.py, définissez TIME_ZONE sur votre fuseau horaire.

Notez également la configuration INSTALLED_APPS en haut du fichier. Elle contient les noms de toutes les applications Django qui sont activées dans cette instance de Django. Les applications peuvent être utilisées dans plusieurs projets, et vous pouvez les emballer et les distribuer pour qu'autrui les utilise dans leurs projets.

Par défaut, INSTALLED_APPS contient les applications suivantes, toutes fournies avec Django :

• django.contrib.admin -- Le site d'administration. Vous l'utiliserez bientôt.
• django.contrib.auth -- Un système d'authentification.
• django.contrib.contenttypes -- Un cadre pour les types de contenu.
• django.contrib.sessions -- Un cadre de sessions.
• django.contrib.messages -- Un cadre de messagerie.
• django.contrib.staticfiles -- Un cadre pour la gestion des fichiers statiques.

Ces applications sont incluses par défaut pour la commodité du cas général.

Certaines de ces applications utilisent au moins une table de base de données, donc nous devons créer les tables dans la base de données avant de pouvoir les utiliser. Pour cela, exécutez la commande suivante :

cd ~/project/mysite
python manage.py migrate

Opérations à effectuer :
  Appliquer toutes les migrations : admin, auth, contenttypes, sessions
Exécution des migrations :
  Appliquer contenttypes.0001_initial... OK
  Appliquer auth.0001_initial... OK
  Appliquer admin.0001_initial... OK
  Appliquer admin.0002_logentry_remove_auto_add... OK
  Appliquer admin.0003_logentry_add_action_flag_choices... OK
  Appliquer contenttypes.0002_remove_content_type_name... OK
  Appliquer auth.0002_alter_permission_name_max_length... OK
  Appliquer auth.0003_alter_user_email_max_length... OK
  Appliquer auth.0004_alter_user_username_opts... OK
  Appliquer auth.0005_alter_user_last_login_null... OK
  Appliquer auth.0006_require_contenttypes_0002... OK
  Appliquer auth.0007_alter_validators_add_error_messages... OK
  Appliquer auth.0008_alter_user_username_max_length... OK
  Appliquer auth.0009_alter_user_last_name_max_length... OK
  Appliquer auth.0010_alter_group_name_max_length... OK
  Appliquer auth.0011_update_proxy_permissions... OK
  Appliquer auth.0012_alter_user_first_name_max_length... OK
  Appliquer sessions.0001_initial... OK

La commande migrate examine la configuration INSTALLED_APPS et crée toutes les tables de base de données nécessaires selon les paramètres de base de données dans votre fichier mysite/settings.py et les migrations de base de données fournies avec l'application (nous aborderons cela plus tard). Vous verrez un message pour chaque migration qu'elle applique. Si vous êtes intéressé, exécutez le client de ligne de commande de votre base de données et tapez \dt (PostgreSQL), SHOW TABLES; (MariaDB, MySQL), .tables (SQLite) ou SELECT TABLE_NAME FROM USER_TABLES; (Oracle) pour afficher les tables créées par Django.

Pour les minimalistes

Comme nous l'avons dit ci-dessus, les applications par défaut sont incluses pour le cas général, mais pas tout le monde en a besoin. Si vous n'en avez pas besoin ou que vous n'en avez besoin que partiellement, n'hésitez pas à commenter ou à supprimer la ligne appropriée de INSTALLED_APPS avant d'exécuter migrate. La commande migrate ne lancera que les migrations pour les applications dans INSTALLED_APPS.

Création de modèles

Maintenant, nous allons définir vos modèles - essentiellement, la structure de votre base de données, avec des métadonnées supplémentaires.

Un modèle est la source unique et définitive d'informations sur vos données. Il contient les champs essentiels et les comportements des données que vous stockez. Django suit le Principe DRY <dry>. L'objectif est de définir votre modèle de données à un seul endroit et de dériver automatiquement les choses à partir de celui-ci.

Cela inclut les migrations - contrairement à Ruby On Rails, par exemple, les migrations sont entièrement dérivées de votre fichier de modèles et sont essentiellement une histoire que Django peut parcourir pour mettre à jour votre schéma de base de données pour qu'il corresponde à vos modèles actuels.

Dans notre application de sondage, nous allons créer deux modèles : Question et Choice. Une Question a une question et une date de publication. Un Choice a deux champs : le texte du choix et un compteur de votes. Chaque Choice est associé à une Question.

Ces concepts sont représentés par des classes Python. Éditez le fichier polls/models.py pour qu'il ressemble à ceci :

from django.db import models


class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField("date published")


class Choice(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

Ici, chaque modèle est représenté par une classe qui hérite de django.db.models.Model. Chaque modèle a un certain nombre de variables de classe, chacune représentant un champ de base de données dans le modèle.

Chaque champ est représenté par une instance d'une classe ~django.db.models.Field - par exemple, ~django.db.models.CharField pour les champs de caractères et ~django.db.models.DateTimeField pour les dates et heures. Cela indique à Django quel type de données chaque champ contient.

Le nom de chaque instance de ~django.db.models.Field (par exemple question_text ou pub_date) est le nom du champ, au format convivial pour les machines. Vous utiliserez cette valeur dans votre code Python, et votre base de données l'utilisera comme nom de colonne.

Vous pouvez utiliser un premier argument positionnel optionnel d'un ~django.db.models.Field pour désigner un nom lisible par l'homme. Cela est utilisé dans plusieurs parties introspectives de Django et sert également de documentation. Si ce champ n'est pas fourni, Django utilisera le nom lisible par les machines. Dans cet exemple, nous avons seulement défini un nom lisible par l'homme pour Question.pub_date. Pour tous les autres champs de ce modèle, le nom lisible par les machines du champ suffira comme nom lisible par l'homme.

Certaines classes ~django.db.models.Field ont des arguments requis. ~django.db.models.CharField, par exemple, nécessite que vous lui donniez un ~django.db.models.CharField.max_length. Cela est utilisé non seulement dans le schéma de base de données, mais également dans la validation, comme nous le verrons bientôt.

Un ~django.db.models.Field peut également avoir divers arguments optionnels ; dans ce cas, nous avons défini la valeur ~django.db.models.Field.default de votes sur 0.

Enfin, notez qu'une relation est définie, en utilisant ~django.db.models.ForeignKey. Cela indique à Django que chaque Choice est lié à une seule Question. Django prend en charge toutes les relations de base de données courantes : plusieurs-vers-un, plusieurs-vers-plusieurs et un-vers-un.

Activation des modèles

Ce petit bout de code de modèle fournit beaucoup d'informations à Django. Avec cela, Django est capable de :

• Créer un schéma de base de données (CREATE TABLE statements) pour cette application.
• Créer une API d'accès à la base de données en Python pour accéder aux objets Question et Choice.

Mais tout d'abord, nous devons informer notre projet que l'application polls est installée.

Les applications Django sont "pluggables" : vous pouvez utiliser une application dans plusieurs projets, et vous pouvez distribuer des applications, car elles n'ont pas besoin d'être liées à une installation de Django donnée.

Pour inclure l'application dans notre projet, nous devons ajouter une référence à sa classe de configuration dans la configuration INSTALLED_APPS. La classe PollsConfig se trouve dans le fichier polls/apps.py, donc son chemin ponctué est 'polls.apps.PollsConfig'. Éditez le fichier mysite/settings.py et ajoutez ce chemin ponctué à la configuration INSTALLED_APPS. Cela devrait ressembler à ceci :

INSTALLED_APPS = [
    "polls.apps.PollsConfig",
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
]

Maintenant, Django sait qu'il doit inclure l'application polls. Exécutons une autre commande :

python manage.py makemigrations polls

Vous devriez voir quelque chose de similaire au suivant :

Migrations pour 'polls' :
  polls/migrations/0001_initial.py
    - Créer le modèle Question
    - Créer le modèle Choice

En exécutant makemigrations, vous dites à Django que vous avez apporté certaines modifications à vos modèles (dans ce cas, vous avez créé de nouveaux modèles) et que vous souhaitez que les modifications soient stockées sous forme de migration.

Les migrations sont la manière dont Django stocke les modifications apportées à vos modèles (et donc à votre schéma de base de données) - ce sont des fichiers sur le disque. Vous pouvez lire la migration pour votre nouveau modèle si vous le souhaitez ; il s'agit du fichier polls/migrations/0001_initial.py. Ne vous inquiétez pas, vous n'êtes pas censé les lire chaque fois que Django en crée une, mais ils sont conçus pour être modifiables à la main au cas où vous souhaiteriez modifier manuellement la manière dont Django modifie les choses.

Il existe une commande qui exécutera les migrations pour vous et gérera automatiquement votre schéma de base de données - c'est la commande migrate, et nous y reviendrons tout de suite - mais tout d'abord, voyons quelle requête SQL cette migration exécuterait. La commande sqlmigrate prend les noms de migrations et renvoie leur SQL :

python manage.py sqlmigrate polls 0001

Vous devriez voir quelque chose de similaire au suivant (nous l'avons reformatté pour plus de lisibilité) :

BEGIN;
--
-- Créer le modèle Question
--
CREATE TABLE "polls_question" (
    "id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
    "question_text" varchar(200) NOT NULL,
    "pub_date" timestamp with time zone NOT NULL
);
--
-- Créer le modèle Choice
--
CREATE TABLE "polls_choice" (
    "id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
    "choice_text" varchar(200) NOT NULL,
    "votes" integer NOT NULL,
    "question_id" bigint NOT NULL
);
ALTER TABLE "polls_choice"
  ADD CONSTRAINT "polls_choice_question_id_c5b4b260_fk_polls_question_id"
    FOREIGN KEY ("question_id")
    REFERENCES "polls_question" ("id")
    DEFERRABLE INITIALLY DEFERRED;
CREATE INDEX "polls_choice_question_id_c5b4b260" ON "polls_choice" ("question_id");

COMMIT;

Remarquez ceci :

• La sortie exacte variera selon la base de données que vous utilisez. L'exemple ci-dessus est généré pour PostgreSQL.
• Les noms de tables sont générés automatiquement en combinant le nom de l'application (polls) et le nom en minuscules du modèle - question et choice. (Vous pouvez modifier ce comportement.)
• Les clés primaires (IDs) sont ajoutées automatiquement. (Vous pouvez également modifier cela.)
• Par convention, Django ajoute "_id" au nom du champ de clé étrangère. (Oui, vous pouvez également modifier cela.)
• La relation de clé étrangère est explicitée par une contrainte FOREIGN KEY. Ne vous inquiétez pas des parties DEFERRABLE ; elle indique à PostgreSQL de ne pas appliquer la contrainte de clé étrangère jusqu'à la fin de la transaction.
• Elle est adaptée à la base de données que vous utilisez, donc les types de champs spécifiques à la base de données tels que auto_increment (MySQL), bigint PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY (PostgreSQL) ou integer primary key autoincrement (SQLite) sont gérés automatiquement pour vous. Il en est de même pour la cote des noms de champs - par exemple, en utilisant des guillemets doubles ou des guillemets simples.
• La commande sqlmigrate n'exécute pas réellement la migration sur votre base de données - au lieu de cela, elle l'affiche à l'écran afin que vous puissiez voir quelle requête SQL Django estime nécessaire. C'est utile pour vérifier ce que Django va faire ou si vous avez des administrateurs de base de données qui exigent des scripts SQL pour les modifications.

Si vous êtes intéressé, vous pouvez également exécuter python manage.py check <check> ; cela vérifie s'il y a des problèmes dans votre projet sans effectuer de migrations ni toucher la base de données.

Maintenant, exécutez migrate à nouveau pour créer ces tables de modèles dans votre base de données :

python manage.py migrate

Opérations à effectuer :
  Appliquer toutes les migrations : admin, auth, contenttypes, polls, sessions
Exécution des migrations :
  Appliquer polls.0001_initial... OK

La commande migrate prend toutes les migrations qui n'ont pas été appliquées (Django suit les migrations appliquées en utilisant une table spéciale dans votre base de données appelée django_migrations) et les exécute sur votre base de données - essentiellement, elle synchronise les modifications que vous avez apportées à vos modèles avec le schéma dans la base de données.

Les migrations sont très puissantes et vous permettent de modifier vos modèles au fil du temps, au fur et à mesure que vous développez votre projet, sans avoir à supprimer votre base de données ou vos tables et à en créer de nouvelles - elle se spécialise dans la mise à jour en direct de votre base de données, sans perte de données. Nous aborderons cela plus en détail dans une partie ultérieure du tutoriel, mais pour l'instant, rappelez-vous le guide en trois étapes pour apporter des modifications aux modèles :

• Modifiez vos modèles (dans models.py).
• Exécutez python manage.py makemigrations <makemigrations> pour créer des migrations pour ces modifications
• Exécutez python manage.py migrate <migrate> pour appliquer ces modifications à la base de données.

La raison pour laquelle il existe des commandes distinctes pour créer et appliquer les migrations est que vous commettrez les migrations dans votre système de contrôle de version et les livrerez avec votre application ; elles facilitent non seulement votre développement, mais sont également utilisables par d'autres développeurs et en production.

Lisez la documentation django-admin </ref/django-admin> pour plus d'informations sur ce que peut faire l'utilitaire manage.py.

Expérimentons l'API

Maintenant, allons dans l'interpréteur de commandes Python interactif et testons l'API gratuite que Django vous offre. Pour invoquer l'interpréteur de commandes Python, utilisez cette commande :

python manage.py shell

Nous utilisons cela plutôt que de simplement taper "python" car manage.py définit la variable d'environnement DJANGO_SETTINGS_MODULE, qui fournit à Django le chemin d'importation Python vers votre fichier mysite/settings.py.

Une fois que vous êtes dans l'interpréteur de commandes, explorez l'API de base de données </topics/db/queries> :

>>> from polls.models import Choice, Question  ## Importez les classes de modèles que nous venons d'écrire.

## Il n'y a pas de questions dans le système pour le moment.
>>> Question.objects.all()
<QuerySet []>

## Créez une nouvelle Question.
## La prise en charge des fuseaux horaires est activée dans le fichier de paramètres par défaut, donc
## Django attend une date et heure avec une information de fuseau horaire pour pub_date. Utilisez timezone.now()
## au lieu de datetime.datetime.now() et cela fonctionnera correctement.
>>> from django.utils import timezone
>>> q = Question(question_text="Quoi de neuf?", pub_date=timezone.now())

## Enregistrez l'objet dans la base de données. Vous devez appeler save() explicitement.
>>> q.save()

## Maintenant, il a un ID.
>>> q.id
1

## Accédez aux valeurs des champs du modèle via des attributs Python.
>>> q.question_text
"Quoi de neuf?"
>>> q.pub_date
datetime.datetime(2023, 9, 7, 1, 18, 48, 335644, tzinfo=datetime.timezone.utc)

## Changez les valeurs en modifiant les attributs, puis appelez save().
>>> q.question_text = "Quoi de neuf?"
>>> q.save()

## objects.all() affiche toutes les questions dans la base de données.
>>> Question.objects.all()
<QuerySet [<Question: Question object (1)>]>

Attendez une minute. <Question: Question object (1)> n'est pas une représentation utile de cet objet. Corrigeons cela en modifiant le modèle Question (dans le fichier polls/models.py) et en ajoutant une méthode ~django.db.models.Model.__str__ à Question et Choice :

from django.db import models


class Question(models.Model):
    #...
    def __str__(self):
        return self.question_text


class Choice(models.Model):
    #...
    def __str__(self):
        return self.choice_text

Il est important d'ajouter des méthodes ~django.db.models.Model.__str__ à vos modèles, non seulement pour votre propre commodité lors de l'utilisation de l'interpréteur interactif, mais également parce que les représentations des objets sont utilisées dans tout l'administrateur automatiquement généré par Django.

Ajoutons également une méthode personnalisée à ce modèle :

import datetime

from django.db import models
from django.utils import timezone


class Question(models.Model):
    #...
    def was_published_recently(self):
        return self.pub_date >= timezone.now() - datetime.timedelta(days=1)

Notez l'ajout de import datetime et from django.utils import timezone, pour référencer respectivement le module datetime standard de Python et les utilitaires liés aux fuseaux horaires de Django dans django.utils.timezone. Si vous n'êtes pas familier avec la gestion des fuseaux horaires en Python, vous pouvez en apprendre plus dans la documentation sur la prise en charge des fuseaux horaires </topics/i18n/timezones>.

Enregistrez ces modifications et lancez un nouvel interpréteur interactif Python en exécutant python manage.py shell à nouveau :

>>> from polls.models import Choice, Question

## Assurez-vous que notre ajout de __str__() a fonctionné.
>>> Question.objects.all()
<QuerySet [<Question: Quoi de neuf?>]>

## Django fournit une riche API de recherche de base de données entièrement basée sur
## des arguments clés.
>>> Question.objects.filter(id=1)
<QuerySet [<Question: Quoi de neuf?>]>
>>> Question.objects.filter(question_text__startswith="Quoi")
<QuerySet [<Question: Quoi de neuf?>]>

## Obtenez la question publiée cette année.
>>> from django.utils import timezone
>>> current_year = timezone.now().year
>>> Question.objects.get(pub_date__year=current_year)
<Question: Quoi de neuf?>

## Demandez un ID qui n'existe pas, cela entraînera une exception.
>>> Question.objects.get(id=2)
Traceback (most recent call last):
 ...
DoesNotExist: Question matching query does not exist.

## La recherche par clé primaire est le cas le plus courant, donc Django fournit un
## raccourci pour les recherches exactes par clé primaire.
## Ce qui suit est identique à Question.objects.get(id=1).
>>> Question.objects.get(pk=1)
<Question: Quoi de neuf?>

## Assurez-vous que notre méthode personnalisée a fonctionné.
>>> q = Question.objects.get(pk=1)
>>> q.was_published_recently()
True

## Donnez à la Question quelques Choix. L'appel create construit un nouveau
## objet Choice, exécute l'instruction INSERT, ajoute le choix à l'ensemble
## des choix disponibles et renvoie le nouveau objet Choice. Django crée
## un ensemble pour stocker l'autre côté d'une relation de clé étrangère
## (par exemple, les choix d'une question) qui peut être consulté via l'API.
>>> q = Question.objects.get(pk=1)

## Affichez tous les choix de l'ensemble d'objets liés - aucun pour le moment.
>>> q.choice_set.all()
<QuerySet []>

## Créez trois choix.
>>> q.choice_set.create(choice_text="Pas grand-chose", votes=0)
<Choice: Pas grand-chose>
>>> q.choice_set.create(choice_text="Le ciel", votes=0)
<Choice: Le ciel>
>>> c = q.choice_set.create(choice_text="En train de hacker encore", votes=0)

## Les objets Choice ont accès via l'API à leurs objets Question liés.
>>> c.question
<Question: Quoi de neuf?>

## Et vice versa : les objets Question ont accès aux objets Choice.
>>> q.choice_set.all()
<QuerySet [<Choice: Pas grand-chose>, <Choice: Le ciel>, <Choice: En train de hacker encore>]>
>>> q.choice_set.count()
3

## L'API suit automatiquement les relations aussi loin que nécessaire.
## Utilisez des doubles tirets pour séparer les relations.
## Cela fonctionne à plusieurs niveaux de profondeur que vous voulez ; il n'y a pas de limite.
## Trouvez tous les Choix pour toute question dont la pub_date est cette année
## (en réutilisant la variable 'current_year' que nous avons créée ci-dessus).
>>> Choice.objects.filter(question__pub_date__year=current_year)
<QuerySet [<Choice: Pas grand-chose>, <Choice: Le ciel>, <Choice: En train de hacker encore>]>

## Supprimons l'un des choix. Utilisez delete() pour cela.
>>> c = q.choice_set.filter(choice_text__startswith="En train de hacker")
>>> c.delete()

Pour plus d'informations sur les relations de modèles, consultez Accès aux objets liés </ref/models/relations>. Pour en savoir plus sur la manière d'utiliser les doubles tirets pour effectuer des recherches de champs via l'API, consultez Recherches de champs <field-lookups-intro>. Pour plus de détails sur l'API de base de données, consultez notre Référence de l'API de base de données </topics/db/queries>.

Présentation de l'administrateur Django

Générer des sites d'administration pour votre personnel ou vos clients afin qu'ils puissent ajouter, modifier et supprimer du contenu est un travail fastidieux qui ne nécessite pas beaucoup de créativité. Pour cette raison, Django automatise entièrement la création d'interfaces d'administration pour les modèles.

Django a été écrit dans un environnement de rédaction d'actualités, avec une séparation très claire entre les "éditeurs de contenu" et le site "public". Les gestionnaires de site utilisent le système pour ajouter des articles d'actualité, des événements, des scores sportifs, etc., et ce contenu est affiché sur le site public. Django résout le problème de la création d'une interface unifiée pour les administrateurs de site pour éditer le contenu.

L'administrateur n'est pas destiné à être utilisé par les visiteurs du site. C'est pour les gestionnaires de site.

Création d'un utilisateur administrateur

Tout d'abord, nous devons créer un utilisateur qui peut se connecter au site d'administration. Exécutez la commande suivante :

python manage.py createsuperuser

Entrez le nom d'utilisateur souhaité et appuyez sur Entrée.

Nom d'utilisateur : admin

Vous serez ensuite invité à entrer votre adresse e-mail souhaitée :

Adresse e-mail : admin@example.com

La dernière étape est d'entrer votre mot de passe. Vous devrez entrer votre mot de passe deux fois, la deuxième fois comme confirmation de la première.

Mot de passe : 12345678
Confirmez le mot de passe : 12345678

Ce mot de passe est trop courant.
Ce mot de passe est entièrement numérique.
Bypasser la validation du mot de passe et créer l'utilisateur malgré tout? [y/N] : y
Superutilisateur créé avec succès.

Démarrer le serveur de développement

Le site d'administration Django est activé par défaut. Démarrons le serveur de développement et explorons-le.

Si le serveur n'est pas en cours d'exécution, démarrez-le comme ceci :

python manage.py runserver

Maintenant, ouvrez un navigateur web dans l'onglet VNC et accédez à "/admin/" sur votre domaine local - par exemple, http://127.0.0.1:8000/admin/. Vous devriez voir l'écran de connexion de l'administrateur :

Depuis que la traduction </topics/i18n/translation> est activée par défaut, si vous définissez LANGUAGE_CODE, l'écran de connexion sera affiché dans la langue donnée (si Django dispose de traductions appropriées).

Entrer dans le site d'administration

Maintenant, essayez de vous connecter avec le compte de superutilisateur que vous avez créé dans l'étape précédente. Vous devriez voir la page d'accueil de l'administrateur Django :

Vous devriez voir quelques types de contenu éditable : groupes et utilisateurs. Ils sont fournis par django.contrib.auth, le cadre d'authentification fourni par Django.

Rendre l'application de sondage modifiable dans l'administrateur

Mais où est notre application de sondage? Elle n'est pas affichée sur la page d'accueil de l'administrateur.

Il ne reste plus qu'une chose à faire : nous devons dire à l'administrateur que les objets Question ont une interface d'administration. Pour ce faire, ouvrez le fichier polls/admin.py et modifiez-le pour qu'il ressemble à ceci :

from django.contrib import admin

from.models import Question

admin.site.register(Question)

Explorer la fonctionnalité d'administrateur gratuite

Maintenant que nous avons enregistré Question, Django sait qu'elle devrait être affichée sur la page d'accueil de l'administrateur :

Cliquez sur "Questions". Maintenant, vous êtes sur la page de "liste de modification" des questions. Cette page affiche toutes les questions dans la base de données et vous permet de choisir une pour la modifier. Il y a la question "Quoi de neuf?" que nous avons créée plus tôt :

Cliquez sur la question "Quoi de neuf?" pour l'éditer :

Points à noter ici :

• Le formulaire est automatiquement généré à partir du modèle Question.
• Les différents types de champs de modèle (~django.db.models.DateTimeField, ~django.db.models.CharField) correspondent au widget d'entrée HTML approprié. Chaque type de champ sait comment s'afficher dans l'administrateur Django.
• Chaque ~django.db.models.DateTimeField bénéficie de raccourcis JavaScript gratuits. Les dates ont un raccourci "Aujourd'hui" et une fenêtre contextuelle de calendrier, et les heures ont un raccourci "Maintenant" et une fenêtre contextuelle pratique qui liste les heures couramment entrées.

La partie inférieure de la page vous offre quelques options :

• Enregistrer - Enregistre les modifications et revient à la page de liste de modification de ce type d'objet.
• Enregistrer et continuer l'édition - Enregistre les modifications et recharge la page d'administrateur de cet objet.
• Enregistrer et ajouter un autre - Enregistre les modifications et charge un nouveau formulaire vide de ce type d'objet.
• Supprimer - Affiche une page de confirmation de suppression.

Si la valeur de "Date publiée" ne correspond pas à l'heure à laquelle vous avez créé la question dans Création d'une application de sondage de base, cela signifie probablement que vous avez oublié de définir la valeur correcte pour la configuration TIME_ZONE. Changez-la, rechargez la page et vérifiez que la valeur correcte apparaît.

Changez la "Date publiée" en cliquant sur les raccourcis "Aujourd'hui" et "Maintenant". Ensuite, cliquez sur "Enregistrer et continuer l'édition". Ensuite, cliquez sur "Histoire" dans le coin supérieur droit. Vous verrez une page listant toutes les modifications apportées à cet objet via l'administrateur Django, avec le horodatage et le nom d'utilisateur de la personne qui a effectué la modification :

Lorsque vous serez à l'aise avec l'API des modèles et que vous vous serez familiarisé avec le site d'administrateur, lisez Création des vues d'interface publique pour en savoir plus sur la manière d'ajouter plus de vues à notre application de sondages.

Sommaire

Félicitations! Vous avez terminé le laboratoire de configuration de la base de données. Vous pouvez pratiquer d'autres laboratoires dans LabEx pour améliorer vos compétences.