La recherche Full Text avec Solr

Configurer un moteur de recherche performant à l'aide d'Apache Lucene/Solr et Apache Tomcat
Solr


précédentsommairesuivant

VII. L'API du noyau : solrconfig.xml

Si le fichier schema.xml regroupe l'intelligence d'un noyau Solr, le fichier solrconfig.xml, quant à lui, regroupe sa configuration. On y trouvera des directives pour localiser les fichiers des classes Java à utiliser, le comportement par défaut de certaines classes, ainsi que la description de l'API de notre noyau.

Cette page sert de référence au reste de l'article. Si vous n'avez pas la patience de la lire de bout en bout à la première lecture, ce qui serait tout à fait normal, n'hésitez pas à passer à la suite pour le moment. Vous pourrez revenir sur cette page lorsque vous aurez besoin de configurer votre schéma ou votre API.

À tout moment, vous pouvez regarder le fichier example/solr/conf/solrconfig.xmlSchéma d'exemple de l'archive téléchargée. Ce fichier est très complet et il contient de nombreux commentaires pour vous aider dans vos prises de décisions.

VII-A. Directives de configuration du noyau

Nous avons déjà vu ces directives dans un chapitre précédent : il s'agit d'abortOnConfigurationError pour indiquer à Solr s'il doit poursuivre ou arrêter le chargement du noyau lorsqu'une erreur est rencontrée, ainsi que de dataDir pour localiser le répertoire des fichiers de l'index principal.

 
Sélectionnez
<abortOnConfigurationError>${solr.config.abortOnConfigurationError}</abortOnConfigurationError>
<dataDir>${solr.config.dataDir}</dataDir>

VII-B. Inclusion de classes Java

Dans la mesure où cet article ne détaillera pas les fonctionnalités de plugins de Solr, nous ne nous étendrons pas sur toutes les subtilités de cette directive. Sachez qu'elle existe et qu'elle permet de charger des classes supplémentaires dans Solr.

 
Sélectionnez
<lib dir="../../contrib/extraction/lib" />

VII-C. Pré configurer une requête grâce à un requestHandler

Dans le chapitre "VI. Interroger un index de donnéesInterroger un index de données Solr", nous avons vu que nous pouvons combiner toute une liste de paramètres pour interroger notre index Solr. Malheureusement, les URL pour interroger Solr deviennent très rapidement longues, très longues et difficiles à relire ou à déboguer.

À cet effet, ainsi que pour vous permettre de brancher facilement un système ACL sur vos URL Tomcat, Solr permet de définir des "request handlers" avec un nom arbitraire. Ces request handlers sont configurables avec des valeurs par défaut ou avec des valeurs fixes, selon vos besoins.

Habituellement, on définit au moins les request handlers suivants : "standard", "/update", "/admin" et "/admin/ping". Ils sont réservés par Solr afin de permettre un minimum d'interactions avec l'index.

Exemple de request handlers par défaut :
Sélectionnez
    <requestHandler name="standard" class="solr.SearchHandler" default="true">
        <lst name="defaults">
            <str name="echoHandler">${solr.output.echoHandler}</str>
            <str name="echoParams">${solr.output.echoParams}</str>
            <str name="debugQuery">${solr.output.debugQuery}</str>
        </lst>
    </requestHandler>

    <requestHandler name="/update" class="solr.XmlUpdateRequestHandler" />
    <requestHandler name="/admin" class="solr.admin.AdminHandlers" />

    <requestHandler name="/admin/ping" class="solr.PingRequestHandler">
        <lst name="defaults">
            <str name="qt">standard</str>
            <str name="q">solrpingquery</str>
            <str name="echoParams">none</str>
        </lst>
    </requestHandler>

Ensuite, à vous de voir quels sont les points communs entre vos requêtes les plus fréquentes. Vous pouvez définir des request handlers pour les regrouper par type d'utilisation.

Par exemple, dans le cas d'un site de produits :
  • home : sélection d'après des filtres arbitraires, pas besoin de calculer des filtres ou des suggestions, pas de saisie utilisateur...
  • browse : navigation d'après quelques paramètres arbitraires, besoin de calculer des filtres, pas besoin de suggestions, pas de saisie utilisateur...
  • search : navigation d'après une saisie utilisateur, besoin de calculer des filtres, besoin de suggestions...

Les composants utilisés par chaque requestHandler sont définis dans des tableaux de chaînes représentant les noms des composants (<arr name="..."><str>...</str><str>...</str></arr>). Il y a deux manières de déclarer ces tableaux : soit un unique tableau "components" avec la liste complète des composants à autoriser dans ce requestHandler, soit deux listes "first-components" et "last-components" qui s'ajoutent aux composants par défaut d'un requestHandler de Solr.

Composants par défaut d'un requestHandler :
Sélectionnez
    <arr name="components">
      <str>query</str>
      <str>facet</str>
      <str>mlt</str>
      <str>highlight</str>
      <str>stats</str>
      <str>debug</str>
    </arr>

Dans l'exemple ci-dessus, vous pouvez voir que les paramètres sont définis dans une liste appelée "defaults" (<lst name="defaults">...</lst>). Toutes les valeurs définies ici remplacent les valeurs définies dans schema.xml, et à plus forte raison les valeurs par défaut de Solr.

Dans Solr, un requestHandler se compose des listes suivantes :
  • defaults : ces valeurs peuvent être remplacées au niveau de la requête ;
  • invariants : ces valeurs sont considérées comme finales, elles ne peuvent pas être surchargées au niveau de la requête ;
  • appends : ces valeurs sont ajoutées quoi qu'il en soit aux requêtes faites sur ce requestHandler.

La liste "appends" permet d'ajouter des valeurs à un paramètre multivalué chaque fois qu'il est utilisé dans la requête. Par exemple, si vous avez un champ booléen "inStock" dans votre schéma, vous pouvez le mettre dans la liste "appends" sous la forme "<str name="fq">inStock:true</str>" pour être assuré de n'afficher que des produits en stock.

De son côté, la liste "invariants" restreint l'usage de certains paramètres. Par exemple, vous pouvez bloquer la liste de champs renvoyés (fl) ou les filtres (facet.field, facet.query et facet.date).

Dans le fichier solrconfig.xml, les nœuds <requestHandler> sont positionnés à l'intérieur du nœud <config>.


précédentsommairesuivant

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2010 Guillaume Rossolini. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.