La recherche Full Text avec Solr

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.

<abortOnConfigurationError>${solr.config.abortOnConfigurationError}</abortOnConfigurationError>
<dataDir>${solr.config.dataDir}</dataDir>

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.

<lib dir="../../contrib/extraction/lib" />

Dans le chapitre « VI. Interroger un index de données », 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.

    <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.

    <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).