ORM

1. Comprendre un modèle

Pour visualiser le code relatif à ce chapitre : git diff v1.1.9..v1.2.0.

Nous poursuivrons le travail sur l’application fil rouge app, tout en utilisant ponctuellement l’application example. Celle-ci regroupe des modèles génériques destinés à tester des mécanismes techniques, sans objectif fonctionnel particulier.

Il vous arrivera également de devoir travailler sur des applications Django que vous n’avez pas créées, mais que vous devez modifier.

Pour cela, il est utile de pouvoir modéliser rapidement une application ; c’est aussi l’une des raisons pour lesquelles nous avons installé django-extensions.

$ make bash  

$ mkdir -p doc/models 
$ poetry run python manage.py graph_models example --pydot -o 
doc/models/example.png 
$ poetry run python manage.py graph_models auth --pydot -o 
doc/models/auth.png 
$ poetry run python manage.py graph_models contenttypes --pydot 
-o doc/models/content_types.png  

La première ligne crée un nouveau répertoire, la seconde crée une image pour représenter le modèle de données d’une application Django en particulier, à savoir example.

La troisième et la quatrième commande font exactement la même chose, mais pour une application Django faisant partie du code de Django lui-même.

Une fois le répertoire créé, on peut ajouter deux commandes : l’une pour afficher tous les modèles du projet, l’autre pour afficher ceux de l’application fil rouge.

Ainsi, dans le fichier Makefile de la racine, on va rajouter :

.PHONY: graph_app_models 
graph_app_models: 
  docker compose run tuto_django poetry run python manage.py 
graph_models app --pydot -o doc/models/app.png 
 
.PHONY:  graph_project_models 
graph_project_models: 
  docker compose run tuto_django poetry run python manage.py 
graph_models --pydot -a -g -o doc/models/project.png  

Cela nous permettra de générer ces fichiers à chaque modification de notre fil rouge, par une simple commande :

$ make graph_app_models ...

1. Créer un manager personnalisé

Pour visualiser le code relatif à ce chapitre : git diff v1.2.0..v1.2.1.

La classe Manager est le nom que l’on donne à cet objet qui nous permet de faire des requêtes (lui-même étant représenté par l’objet QuerySet), à savoir l’attribut objects des modèles.

Cet objet peut être personnalisé.

Pour créer un manager, nous allons créer, dans le fichier managers.py, une classe telle que celle-ci :

class GameManager(models.Manager): 
 
    def get_queryset(self): 
        queryset = super().get_queryset() 
        return queryset.prefetch_related("question_set", 
"question_set__answer_set") 
 
    @property 
    def playable(self): 
        queryset = self.get_queryset() 
        return queryset.filter(status=GameStatus.ONGOING)  

La première méthode est la plus importante : elle définit la requête de base à partir de laquelle toutes les autres seront construites.

Nous récupérons d’abord la requête parente, puis nous ajoutons prefetch_related pour précharger automatiquement toutes les questions et toutes les réponses, comme dans la section précédente.

Pour rappel, cela signifie que l’on crée une requête SQL pour précharger toutes les questions et qu’on l’exécute juste après la requête principale, puis une autre requête pour précharger toutes les réponses.

La seconde méthode a une portée fonctionnelle : elle distingue les jeux jouables, c’est-à-dire ceux dont le statut vaut ONGOING. Le décorateur property évite d’ajouter des parenthèses à l’appel, ce qui rend l’écriture plus lisible et plus cohérente sémantiquement.

Cela sera un moyen simple de pouvoir sélectionner tous les jeux lorsque l’on est dans l’interface d’administration ou seulement les jeux pour les utilisateurs lorsque l’on est dans l’application....

1. Sauvegarder des données

Pour visualiser le code relatif à ce chapitre : git diff v1.2.1..v1.2.2

Les fixtures sont des fichiers contenant des données que l’on peut extraire d’une base de données, puis réinjecter dans une autre base de données.

Ces données peuvent être des données techniques ou des données initiales. Par exemple, si on avait souhaité que la typologie des niveaux d’un jeu soit dynamique et non pas statiquement écrite dans une énumération faisant partie du code, nous aurions pu utiliser une table spécifique pour celle-ci. Il aurait alors été possible de la mettre dans une fixture, pour la charger automatiquement lors de l’installation de l’application.

On peut aussi créer un jeu de données sur une plate-forme, puis l’extraire dans une fixture et la réinjecter sur une autre plate-forme, même si cela demande un peu plus de réflexion, puisque dans les fixtures, nous avons des données techniques, telles que les clés primaires. Pour faire ce genre de choses, nous ne devons plus utiliser les clés primaires, car d’une plate-forme à une autre, ces données peuvent changer. La prochaine clé primaire peut être 5 sur une plateforme et 429482 sur une autre. Il convient donc d’être extrêmement prudent.

La solution pour cette problématique spécifique consiste à utiliser des clés naturelles et c’est ce que l’on abordera dans un chapitre dédié.

L’objectif de ce chapitre est de voir comment cela fonctionne et de mettre en place un certain nombre d’outils....