Skip to content

djangodocs

Django 2.2
  • 6.1 current
  • 6.0
  • 5.2 LTS
  • 5.1 unsupported
  • 5.0 unsupported
  • 4.2 unsupported
  • 4.1 unsupported
  • 4.0 unsupported
  • 3.2 unsupported
  • 3.1 unsupported
  • 3.0 unsupported
  • 2.2 unsupported
  • 2.1 unsupported
  • 2.0 unsupported
  • 1.11 unsupported
  • 1.10 unsupported
  • 1.9 unsupported
Français
  • English
  • 简体中文
  • Français
  • 日本語
  • Bahasa Indonesia
  • Português (Brasil)
  • 한국어
  • Español
  • Ελληνικά
  • Polski
Documentation contents
  • Documentation de Django
  • Premiers pas
  • Utilisation de Django
  • Guides pratiques
  • FAQ Django
  • Référence de l’API
    • Applications
    • Infrastructure de contrôle système
    • API des vues intégrées fondées sur les classes
    • Protection contre le détournement de clic (clickjacking)
    • Paquets contrib
      • Le site d’administration de Django
      • django.contrib.auth
      • L’infrastructure des types de contenus (contenttypes)
      • L’application flatpages (pages statiques)
      • GeoDjango
      • django.contrib.humanize
      • L’infrastructure des messages
      • django.contrib.postgres
        • Fonctions d’agrégation spécifiques à PostgreSQL
        • Champs de modèles spécifiques à PostgreSQL
        • Champs et composants de formulaires spécifiques à PostgreSQL
        • Fonctions de bases de données spécifiques à PostgreSQL
        • Index de modèles spécifiques à PostgreSQL
        • Recherches spécifiques à PostgreSQL
        • Opérations de migration de base de données
        • Recherche plein texte
        • Validateurs
      • L’application de redirection
      • Le système des plans de site (sitemap)
      • L’infrastructure des « sites »
      • L’application de gestion des fichiers statiques (staticfiles)
      • L’infrastructure de syndication par flux
    • Protection contre le « Cross site request forgery » (CSRF)
    • Bases de données
    • django-admin et manage.py
    • Exceptions de Django
    • Gestion des fichiers
    • Formulaires
    • Intergiciels (« middleware »)
    • Opérations de migration
    • Modèles
    • Les objets requête et réponse
    • SchemaEditor
    • Réglages
    • Signaux
    • Gabarits
    • TemplateResponse et SimpleTemplateResponse
    • Données Unicode
    • Fonctions utilitaires django.urls
    • Fonctions django.urls à utiliser dans les configurations d’URL
    • Utilitaires Django
    • Validateurs
    • Vues intégrées
  • Méta documentation et divers
  • Glossaire
  • Notes de publication
  • Fonctionnement interne du projet Django
Django 2.2 is no longer supported. It receives no security fixes. Use it for reference only. Latest release
French translation. Contributed by the Django community. 82.5% Help translate
  1. Django 2.2
  2. Référence de l’API
  3. Paquets contrib
  4. django.contrib.postgres

Recherche plein texteLien vers cette rubrique#

Les fonctions de base de données dans le module django.contrib.postgres.search facilitent l’utilisation du moteur de recherche plein texte de PostgreSQL.

Pour les exemples de ce document, nous utiliserons les modèles définis dans Création de requêtes.

Voir aussi

Pour un aperçu de haut niveau de la recherche, consultez la documentation thématique.

L’expression de recherche searchLien vers cette rubrique#

La façon la plus simple d’utiliser la recherche plein texte est de rechercher un seul terme dans une seule colonne de base de données. Par exemple :

Code
>>> Entry.objects.filter(body_text__search='Cheese')
[<Entry: Cheese on Toast recipes>, <Entry: Pizza Recipes>]

Ceci crée un vecteur to_tsvector dans la base de données à partir du champ body_text et une requête plainto_tsquery à partir du terme de recherche 'Cheese', les deux utilisant la configuration de recherche par défaut de la base de données. Les résultats sont obtenus en faisant correspondre la requête et le vecteur.

Pour utiliser l’expression de recherche search, 'django.contrib.postgres' doit figurer dans le réglage INSTALLED_APPS.

SearchVectorLien vers cette rubrique#

class SearchVector(\*expressions, config=None, weight=None)Lien vers cette définition#

La recherche dans un champ unique fonctionne bien mais est plutôt limitée. Les instances Entry que nous recherchons appartiennent à un Blog, qui possède un champ tagline. Pour interroger les deux champs, utilisez un vecteur SearchVector:

Code
>>> from django.contrib.postgres.search import SearchVector
>>> Entry.objects.annotate(
...     search=SearchVector('body_text', 'blog__tagline'),
... ).filter(search='Cheese')
[<Entry: Cheese on Toast recipes>, <Entry: Pizza Recipes>]

Les paramètres à SearchVector peuvent être n’importe quelle Expression ou le nom d’un champ. Plusieurs paramètres seront concaténés par des espaces afin que le document de recherche les inclue tous.

Les objets SearchVector peuvent être combinés ce qui permet de les réutiliser. Par exemple :

Code
>>> Entry.objects.annotate(
...     search=SearchVector('body_text') + SearchVector('blog__tagline'),
... ).filter(search='Cheese')
[<Entry: Cheese on Toast recipes>, <Entry: Pizza Recipes>]

Voir Modification de la configuration de recherche et Pondération des requêtes pour une explication des paramètres config et weight.

SearchQueryLien vers cette rubrique#

class SearchQuery(value, config=None, search_type='plain')Lien vers cette définition#

SearchQuery traduit les termes fournis par l’utilisateur en un objet requête de recherche que la base de données va comparer à un vecteur de recherche. Par défaut, tous les mots fournis par l’utilisateur sont passés par un algorithme de segmentation, puis la recherche de correspondance s’effectue pour tous les termes résultants.

Si search_type vaut 'plain', la valeur par défaut, les termes sont traités comme des mots-clés séparés. Si search_type vaut 'phrase', les termes sont traités comme une phrase unique. Si search_type vaut 'raw', vous pouvez alors fournir un requête de recherche formatée avec des termes et des opérateurs. Lisez la _`documentation de recherche plein texte`_ de PostgreSQL pour explorer les différences et la syntaxe. Exemples :

Code
>>> from django.contrib.postgres.search import SearchQuery
>>> SearchQuery('red tomato')  # two keywords
>>> SearchQuery('tomato red')  # same results as above
>>> SearchQuery('red tomato', search_type='phrase')  # a phrase
>>> SearchQuery('tomato red', search_type='phrase')  # a different phrase
>>> SearchQuery("'tomato' & ('red' | 'green')", search_type='raw')  # boolean operators

Les termes SearchQuery peuvent être combinés logiquement pour fournir plus de souplesse :

Code
>>> from django.contrib.postgres.search import SearchQuery
>>> SearchQuery('meat') & SearchQuery('cheese')  # AND
>>> SearchQuery('meat') | SearchQuery('cheese')  # OR
>>> ~SearchQuery('meat')  # NOT

Voir Modification de la configuration de recherche pour une explication du paramètre config.

New in Django 2.2

Le paramètre search_type a été ajouté.

SearchRankLien vers cette rubrique#

class SearchRank(vector, query, weights=None)Lien vers cette définition#

Nous n’avons jusqu’ici que renvoyés les résultats pour lesquels au moins une correspondance entre le vecteur et la requête est possible. Il est probable que vous souhaitiez trier les résultats par une certaine notion de pertinence. PostgreSQL fournit une fonction de classement qui prend en compte la fréquence d’apparition des termes recherchés dans le document, la proximité de ces termes dans le document et l’importance de l’endroit où les termes se trouvent dans le document. Plus la correspondance est bonne, plus le classement sera élevé. Pour trier par pertinence :

Code
>>> from django.contrib.postgres.search import SearchQuery, SearchRank, SearchVector
>>> vector = SearchVector('body_text')
>>> query = SearchQuery('cheese')
>>> Entry.objects.annotate(rank=SearchRank(vector, query)).order_by('-rank')
[<Entry: Cheese on Toast recipes>, <Entry: Pizza recipes>]

Voir Pondération des requêtes pour une explication du paramètre weights.

Modification de la configuration de rechercheLien vers cette rubrique#

Il est possible de préciser l’attribut config de SearchVector et de SearchQuery afin d’utiliser une configuration de recherche différente. Cela permet d’utiliser des analyseurs et des dictionnaires de langue différents tels que définis par la base de données :

Code
>>> from django.contrib.postgres.search import SearchQuery, SearchVector
>>> Entry.objects.annotate(
...     search=SearchVector('body_text', config='french'),
... ).filter(search=SearchQuery('œuf', config='french'))
[<Entry: Pain perdu>]

La valeur de config peut aussi être stockée dans une autre colonne :

Code
>>> from django.db.models import F
>>> Entry.objects.annotate(
...     search=SearchVector('body_text', config=F('blog__language')),
... ).filter(search=SearchQuery('œuf', config=F('blog__language')))
[<Entry: Pain perdu>]

Pondération des requêtesLien vers cette rubrique#

Les différents champs d’une requête n’ont pas toujours la même pertinence, il est donc possible de pondérer les différents vecteurs avant de les combiner :

Code
>>> from django.contrib.postgres.search import SearchQuery, SearchRank, SearchVector
>>> vector = SearchVector('body_text', weight='A') + SearchVector('blog__tagline', weight='B')
>>> query = SearchQuery('cheese')
>>> Entry.objects.annotate(rank=SearchRank(vector, query)).filter(rank__gte=0.3).order_by('rank')

Le poids devrait correspondre à l’une des lettres suivantes : D, C, B, A. Par défaut, ces poids font référence respectivement aux nombres 0,1, 0,2, 0,4 et 1,0. Si vous souhaitez pondérer de manière différente, passez une liste de quatre nombres flottants à SearchRank pour le paramètre weights dans le même ordre que ci-dessus :

Code
>>> rank = SearchRank(vector, query, weights=[0.2, 0.4, 0.6, 0.8])
>>> Entry.objects.annotate(rank=rank).filter(rank__gte=0.3).order_by('-rank')

PerformanceLien vers cette rubrique#

Il n’est pas nécessaire de disposer d’une configuration de base de données spéciale pour utiliser ces fonctions. Cependant, si vous recherchez dans plus de quelques centaines d’enregistrements, vous risquez de rencontrer des problèmes de performance. La recherche plein texte est un processus plus intensif que la comparaison de la taille d’un nombre entier, par exemple.

Dans le cas où tous les champs dans lesquels vous recherchez sont contenus dans un modèle particulier, vous pouvez créer un index fonctionnel qui correspond au vecteur de recherche que vous souhaitez utiliser. La documentation de PostgreSQL contient des détails sur la création d’index pour la recherche plein texte.

SearchVectorFieldLien vers cette rubrique#

class SearchVectorFieldLien vers cette définition#

Si cette approche devient trop lente, vous pouvez ajouter un champ SearchVectorField à votre modèle. Il faudra assurer son remplissage par des déclencheurs, par exemple, comme expliqué dans la documentation PostgreSQL. Il est alors possible d’interroger le champ comme s’il s’agissait d’un vecteur annoté SearchVector:

Code
>>> Entry.objects.update(search_vector=SearchVector('body_text'))
>>> Entry.objects.filter(search_vector='cheese')
[<Entry: Cheese on Toast recipes>, <Entry: Pizza recipes>]

Similarité par trigrammeLien vers cette rubrique#

Une autre approche de la recherche est la similitude par trigramme. Un trigramme est un groupe de trois caractères consécutifs. En plus de l’expression de recherche trigram_similar, il est possible d’utiliser une certain nombre d’autres expressions.

Pour les utiliser, vous devez activer l’extension pg_trgm dans PostgreSQL. Vous pouvez installer l’extension par une opération de migration TrigramExtension.

TrigramSimilarityLien vers cette rubrique#

class TrigramSimilarity(expression, string, **extra)Lien vers cette définition#

Accepte un nom de champ ou une expression, ainsi qu’une chaîne ou une expression. Renvoie la similitude par trigramme entre les deux paramètres.

Exemple d’utilisation :

Code
>>> from django.contrib.postgres.search import TrigramSimilarity
>>> Author.objects.create(name='Katy Stevens')
>>> Author.objects.create(name='Stephen Keats')
>>> test = 'Katie Stephens'
>>> Author.objects.annotate(
...     similarity=TrigramSimilarity('name', test),
... ).filter(similarity__gt=0.3).order_by('-similarity')
[<Author: Katy Stevens>, <Author: Stephen Keats>]

TrigramDistanceLien vers cette rubrique#

class TrigramDistance(expression, string, **extra)Lien vers cette définition#

Accepte un nom de champ ou une expression, ainsi qu’une chaîne ou une expression. Renvoie la distance par trigramme entre les deux paramètres.

Exemple d’utilisation :

Code
>>> from django.contrib.postgres.search import TrigramDistance
>>> Author.objects.create(name='Katy Stevens')
>>> Author.objects.create(name='Stephen Keats')
>>> test = 'Katie Stephens'
>>> Author.objects.annotate(
...     distance=TrigramDistance('name', test),
... ).filter(distance__lte=0.7).order_by('distance')
[<Author: Katy Stevens>, <Author: Stephen Keats>]

This page as Markdown JSON

Edit this page on GitHub Official version

PreviousOpérations de migration de base de données NextValidateurs

On this page

  • L’expression de recherche search
  • SearchVector
  • SearchQuery
  • SearchRank
  • Modification de la configuration de recherche
  • Pondération des requêtes
  • Performance
    • SearchVectorField
  • Similarité par trigramme
    • TrigramSimilarity
    • TrigramDistance

An unofficial rendering of the Django documentation.

Not affiliated with or endorsed by the Django Software Foundation. The documentation is copyright © Django Software Foundation and individual contributors, and is used under the BSD 3-Clause licence. “Django” is a trademark of the Django Software Foundation.

This translation is the work of the Django i18n community, not of this site. Read the official documentation at docs.djangoproject.com.

👋 Jason Cartwright