From b17a169762efd0a0e73c46ae3f84124a629a2ada Mon Sep 17 00:00:00 2001 From: Fred Date: Wed, 18 Aug 2021 15:22:46 +0200 Subject: [PATCH] =?UTF-8?q?Mise=20=C3=A0=20jour=20de=20'source/part-3-djan?= =?UTF-8?q?go-concepts/queryset.adoc'?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- source/part-3-django-concepts/queryset.adoc | 32 +++++++++++++++++++-- 1 file changed, 29 insertions(+), 3 deletions(-) diff --git a/source/part-3-django-concepts/queryset.adoc b/source/part-3-django-concepts/queryset.adoc index fbc42e8..77d741d 100644 --- a/source/part-3-django-concepts/queryset.adoc +++ b/source/part-3-django-concepts/queryset.adoc @@ -11,7 +11,8 @@ L'ORM de Django (et donc, chacune des classes qui composent votre modèle) propo d'autres filtres à des filtres existants. Ces deux propriétés vont de paire; par défaut, chaque classe de votre modèle propose un attribut `objects`, qui correspond - à un manager (ou un gestionnaire, si vous préférez). Ce gestionnaire constitue l'interface par laquelle vous accéderez à la base de données. Mais pour cela, vous aurez aussi besoin d'appliquer certains requêtes ou filtres. Et pour cela, vous aurez besoin des `querysets`, qui consistent en des ... ensembles de requêtes :-). + à un manager (ou un gestionnaire, si vous préférez). + Ce gestionnaire constitue l'interface par laquelle vous accéderez à la base de données. Mais pour cela, vous aurez aussi besoin d'appliquer certains requêtes ou filtres. Et pour cela, vous aurez besoin des `querysets`, qui consistent en des ... ensembles de requêtes :-). Si on veut connaître la requête SQL sous-jacente à l'exécution du queryset, il suffit d'appeler la fonction str() sur la propriété `query`: @@ -66,9 +67,34 @@ Ajouter les sujets suivants : . Prefetch . select_related - -#### Jointures +==== Gestionnaire de models (managers) et opérations + +Chaque définition de modèle utilise un `Manager`, afin d'accéder à la base de données et traiter nos demandes. +Indirectement, une instance de modèle ne *connait* **pas** la base de données: c'est son gestionnaire qui a cette tâche. +Il existe deux exceptions à cette règle: les méthodes `save()` et `update()`. + +* Instanciation: MyClass() +* Récupération: MyClass.objects.get(pk=...) +* Sauvegarde : MyClass().save() +* Création: MyClass.objects.create(...) +* Liste des enregistrements: MyClass.objects.all() + +Par défaut, le gestionnaire est accessible au travers de la propriété `objects`. +Cette propriété a une double utilité: + +1. Elle est facile à surcharger - il nous suffit de définir une nouvelle classe héritant de ModelManager, puis de définir, au niveau de la classe, une nouvelle assignation à la propriété `objects` +2. Il est tout aussi facile de définir d'autres propriétés présentant des filtres bien spécifiques. + + +==== Requêtes + +DANGER: Les requêtes sont sensibles à la casse, **même** si le moteur de base de données ne l'est pas. +C'est notamment le cas pour Microsoft SQL Server; faire une recherche directement via les outils de Microsoft ne retournera pas +obligatoirement les mêmes résultats que les managers, qui seront beaucoup plus tatillons sur la qualité des recherches par +rapport aux filtres paramétrés en entrée. + +==== Jointures Pour appliquer une jointure sur un modèle, nous pouvons passer par les méthodes `select_related` et `prefetch_related`. Il faut cependant faire **très** attention au prefetch related, qui fonctionne en fait comme une grosse requête dans laquelle