Apprenons avec un exemple.
Tout au long de ce tutoriel, nous vous guiderons dans la création d’une application simple de sondage.
Cela consistera en deux parties :
Un site public qui permet à des gens de voir les sondages et d’y répondre.
Un site d’administration qui permet d’ajouter, de modifier et de supprimer des sondages.
Nous supposerons que Django est déjà installé. Vous pouvez savoir si Django est installé et sa version en exécutant la commande suivante :
python -c "import django; print(django.get_version())"
Si Django est installé, vous devriez voir apparaître la version de l’installation. Dans le cas contraire, vous obtiendrez une erreur disant « No module named django » (aucun module nommé django).
Ce didacticiel est écrit pour Django 1.6 et Python 2.x. Si la version de Django ne correspond pas, référez-vous au didacticiel correspondant à votre version de Django en utilisant le sélecteur de version au bas de cette page, ou mettez à jour Django à la version la plus récente. Si vous utilisez Python 3.x, sachez que votre code peut devoir être différent de celui du didacticiel. Ne suivez ce didacticiel en utilisant Python 3.x que si vous êtes bien au fait des différences entre Python 2.x et Python 3.x.
Consultez Comment installer Django pour tout conseil sur la manière de supprimer d’anciennes versions de Django pour en installer une nouvelle.
Où obtenir de l’aide :
Si vous avez des problèmes au long de ce tutoriel, écrivez un message sur django-users (anglophone) ou passez sur #django-fr sur irc.freenode.net pour discuter avec d’autres utilisateurs de Django qui pourraient vous aider.
Si c’est la première fois que vous utilisez Django, vous devrez vous occuper de quelques éléments de configuration initiaux. Plus précisément, vous devrez lancer la génération automatique de code qui mettra en place un projet Django – un ensemble de réglages particuliers à une instance de Django, qui comprend la configuration de la base de données, des options spécifiques à Django et d’autres propres à l’application.
Depuis un terminal en ligne de commande, déplacez-vous à l’aide de la commande cd dans un répertoire dans lequel vous souhaitez conserver votre code, puis lancez la commande suivante :
django-admin.py startproject mysite
Cela va créer un répertoire mysite dans le répertoire courant. Si cela ne fonctionne pas, consultez Problèmes d’exécution de django-admin.py.
Note
Vous devez éviter de nommer vos projets en utilisant des noms réservés de Python ou des noms de composants de Django. Cela signifie en particulier que vous devez éviter d’utiliser des noms comme django (qui entrerait en conflit avec Django lui-même) ou test (qui entrerait en conflit avec un composant intégré de Python).
À quel endroit ce code devrait-il se trouver ?
Si vous avez une expérience en PHP, vous avez probablement l’habitude de placer votre code dans le répertoire racine de votre serveur Web (comme /var/www/). Avec Django, ne le faites pas. Ce n’est pas une bonne idée de mettre du code Python dans le répertoire racine de votre serveur Web, parce que cela crée le risque que l’on puisse voir votre code sur le Web, ce qui n’est pas bon pour la sécurité.
Mettez votre code dans un répertoire en dehors de la racine de votre serveur Web, comme par exemple home/moncode.
Voyons ce que startproject a créé :
mysite/
manage.py
mysite/
__init__.py
settings.py
urls.py
wsgi.py
Cela ne correspond pas à ce que vous voyez ?
La disposition de projet par défaut a récemment changé. Si vous voyez une disposition « à plat » (sans sous-répertoire mysite/), vous utilisez probablement une version de Django qui ne correspond pas à ce didacticiel. Consultez une version précédente de ce didacticiel ou mettez à jour votre version de Django.
Ces fichiers sont :
Le premier répertoire racine mysite/ n’est qu’un contenant pour votre projet. Son nom n’a pas d’importance pour Django ; vous pouvez le renommer comme vous voulez.
manage.py : un utilitaire en ligne de commande qui vous permet d’interagir avec ce projet Django de différentes façons. Vous trouverez toutes les informations nécessaires sur manage.py dans django-admin.py et manage.py.
Le sous-répertoire mysite/ correspond au paquet Python effectif de votre projet. C’est le nom du paquet Python que vous devrez utiliser pour importer ce qu’il contient (par ex. mysite.urls).
mysite/__init__.py : un fichier vide qui indique à Python que ce répertoire doit être considéré comme un paquet (lisez informations sur les paquets (en) dans la documentation officielle de Python si vous êtes débutant avec ce langage).
mysite/settings.py : réglages et configuration de ce projet Django. Les réglages de Django vous apprendra tout sur le fonctionnement des réglages.
mysite/urls.py : les déclarations des URL de ce projet Django, une sorte de « table des matières » de votre site Django. Vous pouvez en lire plus sur les URL dans Distribution des URL.
mysite/wsgi.py : un point d’entrée pour les serveurs Web compatibles WSGI pour déployer votre projet. Voir Comment déployer avec WSGI pour plus de détails.
Vérifions que tout fonctionne comme prévu. Déplacez-vous dans le répertoire mysite si ce n’est pas déjà fait, et lancez la commande python manage.py runserver. Vous verrez apparaître les messages suivants :
Validating models... 0 errors found January 13, 2016 - 15:50:53 Django version 1.6, using settings 'mysite.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C.
Vous avez démarré le serveur de développement de Django, un serveur Web léger entièrement écrit en Python. Nous l’avons inclus avec Django de façon à vous permettre de développer rapidement, sans avoir à vous occuper de la configuration d’un serveur de production – comme Apache – tant que vous n’en avez pas besoin.
C’est le moment de noter soigneusement ceci : N’UTILISEZ JAMAIS ce serveur pour quoi que ce soit qui s’approche d’un environnement de production. Il est fait seulement pour tester votre travail pendant le développement (notre métier est le développement d’environnements Web, pas de serveurs Web).
Maintenant que le serveur tourne, allez à l’adresse http://127.0.0.1:8000 avec votre navigateur Web. Vous verrez une page avec le message « Welcome to Django » sur un joli fond bleu pastel. Ça marche !
Modification du port
Par défaut, la commande runserver démarre le serveur de développement sur l’IP interne sur le port 8000.
Si vous voulez changer cette valeur, passez-la comme paramètre sur la ligne de commande. Par exemple, cette commande démarre le serveur sur le port 8080 :
$ python manage.py runserver 8080
Si vous voulez changer l’IP du serveur, passez-la comme paramètre avec le port. Pour écouter toutes les IP publiques (utile si vous souhaitez montrer votre travail à des personnes sur d’autres ordinateurs), faites :
$ python manage.py runserver 0.0.0.0:8000
La documentation complète du serveur de développement se trouve dans la référence de runserver.
Rechargement automatique de runserver
Le serveur de développement recharge automatiquement le code Python lors de chaque requête si nécessaire. Vous ne devez pas redémarrer le serveur pour que les changements de code soient pris en compte. Cependant, certaines actions comme l’ajout de fichiers ou la compilation de fichiers de traduction ne provoquent pas de redémarrage, il est donc nécessaire de redémarrer manuellement le serveur dans ces cas.
Maintenant, éditez mysite/settings.py. C’est un module Python tout à fait normal, avec des variables de module qui représentent des réglages de Django.
La configuration par défaut utilise SQLite. Si vous débutez avec les bases de données ou que vous voulez juste essayer Django, il s’agit du choix le plus simple. SQLite est inclus dans Python, vous n’aurez donc rien d’autre à installer pour utiliser ce type de base de données.
Si vous souhaitez utiliser une autre base de données, installez le connecteur de base de données approprié, et changez les clés suivantes dans l’élément 'default' de DATABASES pour indiquer les paramètres de connexion de votre base de données :
ENGINE – Choisissez parmi 'django.db.backends.sqlite3', 'django.db.backends.postgresql_psycopg2', 'django.db.backends.mysql' ou 'django.db.backends.oracle'. D’autres moteurs sont également disponibles.
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 doit être le chemin absolu complet de celui-ci, y compris le nom de fichier. La valeur par défaut, os.path.join(BASE_DIR, 'db.sqlite3'), stocke ce fichier dans le répertoire de votre projet.
Si vous utilisez une autre base de données que SQLite, des réglages supplémentaires doivent être indiqués, comme USER, PASSWORD ou HOST. Pour plus de détails, consultez la documentation de référence de DATABASES.
Note
Si vous utilisez PostgreSQL ou MySQL, assurez-vous maintenant d’avoir créé la base de données. Faites-le avec CREATE DATABASE nom_de_la_base; dans le shell interactif de votre base de données.
Si vous utilisez SQLite, vous n’avez rien à créer à l’avance - le fichier de la base de données sera automatiquement créé lorsque ce sera nécessaire.
Puisque vous êtes en train d’éditer mysite/settings.py, définissez TIME_ZONE selon votre fuseau horaire.
Notez également le réglage INSTALLED_APPS au début du fichier. Cette variable contient le nom des applications Django qui sont actives dans cette instance de Django. Les applications peuvent être utilisées dans des projets différents, et vous pouvez empaqueter et distribuer les vôtres pour que d’autres les utilisent dans leurs projets.
Par défaut, INSTALLED_APPS contient les applications suivantes, qui sont toutes contenues dans Django :
django.contrib.admin – Le site d’administration. Vous l’utiliserez dans la deuxième partie de ce tutoriel.
django.contrib.auth – Un système d’authentification.
django.contrib.contenttypes – Une structure pour les types de contenu (content types).
django.contrib.sessions – Un cadre pour les sessions.
django.contrib.messages – Un cadre pour l’envoi de messages.
django.contrib.staticfiles – Une structure pour la prise en charge des fichiers statiques.
Ces applications sont incluses par défaut par commodité parce que ce sont les plus communément utilisées.
Certaines de ces applications utilisent toutefois au moins une table de la base de données, donc il nous faut créer les tables dans la base avant de pouvoir les utiliser. Pour ce faire, lancez la commande suivante :
$ python manage.py syncdb
La commande syncdb va créer toutes les tables de base de données nécessaires aux applications listées dans le règlage INSTALLED_APPS de votre fichier mysite/settings.py. Vous verrez un message pour chaque table créée, et il vous sera proposé de créer un compte de super-utilisateur pour le système d’authentification. Faites-le.
Si vous le souhaitez, lancez le client de ligne de commande de votre base de données, et saisissez \dt (PostgreSQL), SHOW TABLES; (MySQL) ou .schema (SQLite) pour afficher les tables que Django a créées.
Pour les minimalistes
Comme il a été indiqué ci-dessus, les applications incluses par défaut sont les plus communes, mais tout le monde n’en a pas forcément besoin. Si vous n’avez pas besoin d’une d’entre elles (ou de toutes), vous êtes libre de commenter ou effacer les lignes concernées du réglage INSTALLED_APPS avant de lancer syncdb. La commande syncdb ne créera que les tables nécessaires aux applications listées dans INSTALLED_APPS.
Maintenant que votre environnement – un « projet » – est en place, vous êtes prêt à commencer à travailler.
Chaque application que vous écrivez avec Django est en fait un paquet Python qui respecte certaines conventions. Django est livré avec un utilitaire qui génère automatiquement la structure des répertoires de base d’une application, ce qui vous permet de vous concentrer sur l’écriture du code, plutôt que sur la création de répertoires.
Projets vs. applications
Quelle est la différence entre un projet et une application ? Une application est une application Web qui fait quelque chose – par exemple un système de blog, une base de données publique ou une application de sondage. Un projet est un ensemble de réglages et d’applications pour un site Web particulier. Un projet peut contenir plusieurs applications. Une application peut apparaître dans plusieurs projets.
Vos applications peuvent se trouver à n’importe quel endroit de votre chemin de recherche Python. Dans ce didacticiel, nous allons créer une application de sondage au même niveau que le fichier manage.py pour qu’elle puisse être importée comme module de premier niveau plutôt que comme sous-module de monsite.
Pour créer votre application, assurez-vous d’être dans le même répertoire que manage.py et saisissez cette commande :
$ python manage.py startapp polls
Cela va créer un répertoire polls, qui est structuré de la façon suivante :
polls/
__init__.py
admin.py
models.py
tests.py
views.py
Cette structure de répertoire accueillera l’application de sondage.
La première étape dans l’écriture d’une application Web utilisant une base de données dans Django est la définition de vos modèles – essentiellement, votre schéma de base de données, avec quelques métadonnées supplémentaires.
Philosophie
Un modèle est la source d’information unique et définitive pour vos données. Il contient les champs essentiels et le comportement attendu des données que vous stockerez. Django respecte la philosophie DRY (Don’t Repeat Yourself, « ne vous répétez pas »). Le but est de définir le modèle des données à un seul endroit, et ensuite de dériver automatiquement ce qui est nécessaire à partir de celui-ci.
Dans notre application de sondage simple, nous allons créer deux modèles : Poll (sondage) et Choice (choix). Un sondage possède une question et une date de mise en ligne. Un choix a deux champs : le texte représentant le choix et le décompte des votes. Chaque choix est associé à un sondage.
Ces concepts sont représentés par de simples classes Python. Éditez le fichier polls/models.py de façon à ce qu’il ressemble à ceci :
from django.db import models
class Poll(models.Model):
question = models.CharField(max_length=200)
pub_date = models.DateTimeField('date published')
class Choice(models.Model):
poll = models.ForeignKey(Poll)
choice_text = models.CharField(max_length=200)
votes = models.IntegerField(default=0)
Le code est trivial. Chaque modèle est représenté par une classe qui hérite de django.db.models.Model. Chaque modèle possède des variables de classe, chacune d’entre elles représentant un champ de la base de données pour ce modèle.
Chaque champ est représenté par une instance d’une classe Field – par exemple, CharField pour les champs de type caractère, et DateTimeField pour les champs date et heure. Cela indique à Django le type de données que contient chaque champ.
Le nom de chaque instance de Field (par exemple, question ou pub_date) est le nom du champ en interne. Vous l’utiliserez dans votre code Python et votre base de données l’utilisera comme nom de colonne.
Vous pouvez utiliser le premier paramètre de position (facultatif) d’un Field pour donner un nom plus lisible au champ. Celui-ci est utilisé un peu partout par le système d’introspection de Django, et aussi pour la documentation. Si ce paramètre est absent, Django utilise le nom du champ interne. Dans l’exemple, nous n’avons défini qu’un seul nom plus lisible, pour Poll.pub_date. Pour tous les autres champs, nous avons considéré que le nom interne était suffisamment lisible.
Certaines classes Field possèdent des paramètres obligatoires. La classe CharField, par exemple, a besoin d’un attribut max_length. Ce n’est pas seulement utilisé dans le schéma de base de la base de données, mais également pour valider les champs, comme nous allons voir prochainement.
Un champ Field peut aussi autoriser des paramètres facultatifs ; dans notre cas, nous avons défini à 0 la valeur default de votes.
Finalement, notez que nous définissons une relation, en utilisant ForeignKey. Cela indique à Django que chaque vote (Choice) n’est relié qu’à un seul sondage (Poll). Django propose tous les modèles classiques de relations : plusieurs-à-un, plusieurs-à-plusieurs, un-à-un.
Ce petit morceau de code décrivant les modèles fournit beaucoup d’informations à Django. Cela lui permet de :
Créer un schéma de base de données (instructions CREATE TABLE) pour cette application.
Créer une API Python d’accès à la base de données pour accéder aux objets sondages (Poll) et votes (Choices).
Mais il faut d’abord indiquer à notre projet que l’application de sondages polls est installée.
Philosophie
Les applications de Django sont comme des pièces d’un jeu de construction : vous pouvez utiliser une application dans plusieurs projets, et vous pouvez distribuer les applications, parce qu’elles n’ont pas besoin d’être liées à une installation Django particulière.
Éditez encore une fois le fichier mysite/settings.py et modifiez le réglage INSTALLED_APPS pour qu’il contienne la chaîne de caractères 'polls'. Il devrait donc ressembler à ceci :
INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'polls',
)
Maintenant, Django sait qu’il doit inclure l’application polls. Exécutons une autre commande :
$ python manage.py sql polls
Vous devriez voir quelque chose de similaire à ceci (les instructions SQL CREATE TABLE pour l’application de sondage) :
BEGIN;
CREATE TABLE "polls_poll" (
"id" integer NOT NULL PRIMARY KEY,
"question" varchar(200) NOT NULL,
"pub_date" datetime NOT NULL
);
CREATE TABLE "polls_choice" (
"id" integer NOT NULL PRIMARY KEY,
"poll_id" integer NOT NULL REFERENCES "polls_poll" ("id"),
"choice_text" varchar(200) NOT NULL,
"votes" integer NOT NULL
);
COMMIT;
Notez les points suivants :
Ce que vous verrez dépendra de la base de données que vous utilisez. L’exemple ci-dessus est généré pour SQLite.
Les noms de tables sont générés automatiquement en combinant le nom de l’application (polls) et le nom du modèle en minuscules – poll et choice (vous pouvez modifier ce comportement).
Des clés primaires (ID) sont ajoutées automatiquement (vous pouvez modifier ceci également).
Par convention, Django ajoute "_id" au nom de champ de la clé étrangère. Et oui, vous pouvez aussi changer ça.
La relation de clé étrangère est rendue explicite par une instruction REFERENCES.
Ce que vous voyez est adapté à la base de données que vous utilisez. Ainsi, des champs spécifiques à celle-ci comme auto_increment (MySQL), serial (PostgreSQL) ou integer primary key (SQLite) sont gérés pour vous automatiquement. Tout comme pour les guillemets autour des noms de champs (simples ou doubles).
En réalité, la commande sql n’exécute pas ces instructions dans votre base de données - elle se contente de les afficher à l’écran de façon à vous permettre de voir ce que Django pense nécessaire. Si vous le voulez, vous pourriez copier et coller cette sortie dans le shell de votre client de base de données. Toutefois, comme nous allons le voir bientôt, Django fournit un moyen plus facile d’envoyer ces commandes à la base de données.
Si cela vous intéresse, vous pouvez aussi exécuter les commandes suivantes :
python manage.py validate – Vérifie qu’il n’y a pas d’erreurs dans la construction de vos modèles.
python manage.py sqlcustom polls – Affiche toutes les instructions SQL spécifiques (comme des modifications de table ou des contraintes particulières) qui sont définies pour l’application.
python manage.py sqlclear polls – Affiche les instructions DROP TABLE nécessaires pour cette application, compte tenu des tables qui existent déjà dans votre base de données (s’il y en a).
python manage.py sqlindexes polls – Affiche les instructions CREATE INDEX pour cette application.
python manage.py sqlall polls – Une combinaison des instructions SQL des commandes sql, sqlcustom et sqlindexes.
L’examen de ce qu’affichent ces commandes peut vous aider à comprendre ce qui se passe en coulisses.
Maintenant, exécutez à nouveau la commande syncdb pour créer les tables des modèles dans votre base de données :
$ python manage.py syncdb
La commande syncdb exécute les instructions SQL de sqlall dans votre base de données, pour toutes les applications de INSTALLED_APPS qui n’existent pas encore dans celle-ci. Cela crée toutes les tables, les données initiales et les index pour toutes les applications que vous avez ajoutées à votre projet depuis la dernière exécution de syncdb. syncdb peut être appelée aussi souvent que vous le souhaitez, et ne fera que créer les tables qui n’existent pas encore.
Lisez la documentation de django-admin.py pour obtenir toutes les informations sur ce que l’utilitaire manage.py peut faire.
Maintenant, utilisons un shell interactif Python pour jouer avec l’API que Django met gratuitement à votre disposition. Pour lancer un shell Python, utilisez cette commande :
$ python manage.py shell
Nous utilisons celle-ci au lieu de simplement taper « python », parce que manage.py définit la variable d’environnement DJANGO_SETTINGS_MODULE, qui indique à Django le chemin d’importation Python vers votre fichier mysite/settings.py.
Se passer de manage.py
Si vous préférez ne pas utiliser manage.py, pas de problème. Définissez la variable d’environnement DJANGO_SETTINGS_MODULE à mysite.settings et exécutez python dans le même répertoire que celui où se trouve manage.py (ou assurez-vous que ce répertoire est dans le chemin Python afin que import mysite fonctionne).
Pour plus d’informations sur tout ceci, voyez la documentation de django-admin.py.
Une fois dans le shell, explorez l’API de base de données:
>>> from polls.models import Poll, Choice # Import the model classes we just wrote.
# No polls are in the system yet.
>>> Poll.objects.all()
[]
# Create a new Poll.
# Support for time zones is enabled in the default settings file, so
# Django expects a datetime with tzinfo for pub_date. Use timezone.now()
# instead of datetime.datetime.now() and it will do the right thing.
>>> from django.utils import timezone
>>> p = Poll(question="What's new?", pub_date=timezone.now())
# Save the object into the database. You have to call save() explicitly.
>>> p.save()
# Now it has an ID. Note that this might say "1L" instead of "1", depending
# on which database you're using. That's no biggie; it just means your
# database backend prefers to return integers as Python long integer
# objects.
>>> p.id
1
# Access database columns via Python attributes.
>>> p.question
"What's new?"
>>> p.pub_date
datetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=<UTC>)
# Change values by changing the attributes, then calling save().
>>> p.question = "What's up?"
>>> p.save()
# objects.all() displays all the polls in the database.
>>> Poll.objects.all()
[<Poll: Poll object>]
Une seconde. <Poll: Poll object> n’est, à l’évidence, pas une représentation de cet objet très utile. On va arranger cela en éditant le modèle des sondages (dans le fichier polls/models.py) et en ajoutant une méthode __unicode__() à Poll et à Choice. Avec Python 3, remplacez simplement __unicode__ par __str__ dans l’exemple suivant :
from django.db import models
class Poll(models.Model):
# ...
def __unicode__(self): # Python 3: def __str__(self):
return self.question
class Choice(models.Model):
# ...
def __unicode__(self): # Python 3: def __str__(self):
return self.choice_text
Il est important d’ajouter des méthodes __unicode__() (ou __str__() avec Python 3) à vos modèles, non seulement parce que c’est plus pratique lorsque vous utilisez le shell interactif, mais aussi parce que la représentation des objets est très utilisée dans l’interface d’administration automatique de Django.
__unicode__ ou __str__?
Avec Python 3, les choses sont plus simples ; utilisez uniquement __str__() et oubliez __unicode__().
Si Python 2 vous est familier, vous avez peut-être l’habitude d’ajouter des méthodes __str__() à vos classes, plutôt que __unicode__(). Nous utilisons cette dernière parce que les modèles de Django utilisent Unicode par défaut. Toute l’information stockée dans votre base de données est convertie en Unicode avant de vous être renvoyée.
Les modèles Django ont une méthode __str__() par défaut, qui appelle __unicode__() et convertit le résultat en chaîne d’octets UTF-8. Cela signifie que unicode(p) renverra une chaîne Unicode, et str(p) renverra une chaîne normale, avec les caractères encodés en UTF-8.
Si vous ne comprenez rien à tout ça, rappelez-vous simplement d’ajouter une méthode __unicode__() à vos modèles. Avec un peu de chance, cela suffira pour que tout fonctionne pour vous.
Notez que ce sont des méthodes Python classiques. Ajoutons une méthode personnalisée, juste pour la démonstration :
import datetime
from django.utils import timezone
# ...
class Poll(models.Model):
# ...
def was_published_recently(self):
return self.pub_date >= timezone.now() - datetime.timedelta(days=1)
Notez l’ajout de import datetime et de from django.utils import timezone, pour référencer respectivement le module datetime standard de Python et les utilitaires de Django liés aux fuseaux horaires de django.utils.timezone. Si vous n’êtes pas habitué à la gestion des fuseaux horaires avec Python, vous pouvez en apprendre plus en consultant la documentation sur les fuseaux horaires.
Enregistrez ces modifications et retournons au shell interactif de Python en exécutant à nouveau python manage.py shell:
>>> from polls.models import Poll, Choice
# Make sure our __unicode__() addition worked.
>>> Poll.objects.all()
[<Poll: What's up?>]
# Django provides a rich database lookup API that's entirely driven by
# keyword arguments.
>>> Poll.objects.filter(id=1)
[<Poll: What's up?>]
>>> Poll.objects.filter(question__startswith='What')
[<Poll: What's up?>]
# Get the poll that was published this year.
>>> from django.utils import timezone
>>> current_year = timezone.now().year
>>> Poll.objects.get(pub_date__year=current_year)
<Poll: What's up?>
# Request an ID that doesn't exist, this will raise an exception.
>>> Poll.objects.get(id=2)
Traceback (most recent call last):
...
DoesNotExist: Poll matching query does not exist.
# Lookup by a primary key is the most common case, so Django provides a
# shortcut for primary-key exact lookups.
# The following is identical to Poll.objects.get(id=1).
>>> Poll.objects.get(pk=1)
<Poll: What's up?>
# Make sure our custom method worked.
>>> p = Poll.objects.get(pk=1)
>>> p.was_published_recently()
True
# Give the Poll a couple of Choices. The create call constructs a new
# Choice object, does the INSERT statement, adds the choice to the set
# of available choices and returns the new Choice object. Django creates
# a set to hold the "other side" of a ForeignKey relation
# (e.g. a poll's choices) which can be accessed via the API.
>>> p = Poll.objects.get(pk=1)
# Display any choices from the related object set -- none so far.
>>> p.choice_set.all()
[]
# Create three choices.
>>> p.choice_set.create(choice_text='Not much', votes=0)
<Choice: Not much>
>>> p.choice_set.create(choice_text='The sky', votes=0)
<Choice: The sky>
>>> c = p.choice_set.create(choice_text='Just hacking again', votes=0)
# Choice objects have API access to their related Poll objects.
>>> c.poll
<Poll: What's up?>
# And vice versa: Poll objects get access to Choice objects.
>>> p.choice_set.all()
[<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]
>>> p.choice_set.count()
3
# The API automatically follows relationships as far as you need.
# Use double underscores to separate relationships.
# This works as many levels deep as you want; there's no limit.
# Find all Choices for any poll whose pub_date is in this year
# (reusing the 'current_year' variable we created above).
>>> Choice.objects.filter(poll__pub_date__year=current_year)
[<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]
# Let's delete one of the choices. Use delete() for that.
>>> c = p.choice_set.filter(choice_text__startswith='Just hacking')
>>> c.delete()
Pour plus d’informations sur les relations entre modèles, consultez Accès aux objets liés. Pour en savoir plus sur la manière d’utiliser les doubles soulignements pour explorer les champs par l’API, consultez Recherches par champs. Pour tous les détails sur l’API de base de données, consultez la référence de l’API de base de données.
Lorsque vous serez familiarisé avec l’API, lisez la partie 2 de ce tutoriel pour faire fonctionner l’interface d’administration automatique de Django.
Jan 13, 2016