VI. Interroger un index de données▲
VI-A. Préparation▲
Dans le chapitre III-E, nous avons défini une configuration de solrconfig.xml permettant d’effectuer des requêtes :
<requestHandler name="standard" class="solr.SearchHandler" default="true"/>Dans ce chapitre, nous allons avoir besoin de quelques informations de débogage. Pour les activer, modifiez les fichiers de votre noyau de la manière suivante :
solr.output.echoHandler = true
solr.output.echoParams = explicit <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>
</lst>
</requestHandler>« echoHandler » peut prendre les valeurs « false » ou « true ».
« echoParams » peut prendre les valeurs « none », « explicit » ou « all ».
Pensez à recharger la configuration de Solr après avoir modifié le fichier solrconfig.xml. Pour rappel, cela peut être fait soit en redémarrant Tomcat soit en chargeant l’URL suivante :
http://localhost:8080/solr/admin/cores?core=CORENAME&action=reload
Cette modification ajoute deux éléments « handler » et « params » dans le responseHeader de la réponse. Par exemple, pour la requête effectuée à la fin du chapitre précédent, la réponse de Solr devient :
Un troisième paramètre de débogage peut être ajouté : debugQuery. Il peut prendre les valeurs « false » ou « true ». Il ajoute des informations bien plus détaillées sur la manière dont Solr décompose les requêtes. Sauf pour parfaire votre éducation personnelle ou si vous pensez avoir identifié un bug dans Solr, vous ne devriez pas en avoir besoin.
VI-B. Surcharge de paramètres▲
Ce que j’appelle surcharge de paramètres est la possibilité de modifier la valeur d’un paramètre à tous les niveaux. Lorsque vous effectuez une requête Solr, les paramètres envoyés par HTTP GET sont évalués de la manière suivante :
- Si le requestHandler a défini le paramètre dans la liste des « invariants », alors sa valeur est lue depuis solrconfig.xml ;
-
Sinon, il est déduit dans l’ordre suivant :
- présence dans l’URL ;
- définition dans les « defaults » du requestHandler ;
- définition dans la déclaration du nom du champ dans schema.xml ;
- définition dans la déclaration du nom du type du champ dans schema.xml ;
- valeur par défaut du type du champ (valeur interne de Solr ou de Lucene).
Cela devient pratique dès que vous identifiez un paramètre qui revient très souvent à la même valeur. Puisque tous les composants de Solr peuvent être activés par un paramètre dans l’URL, il est très facile de prototyper une application. Par la suite, nous verrons comment utiliser avantageusement tout cela.
VI-C. Composant solr.StandardRequestHandler▲
Ce composant est très générique. Il permet d’effectuer des requêtes sur l’index et de récupérer les résultats. La majorité des autres composants réutilisent ses paramètres ou ajoutent les leurs.
Paramètres courants :
- q : « query », c’est le paramètre qui contient la chaîne recherchée, qui peut être appliquée à un champ précis ou au champ par défaut ;
- fl : liste de champs renvoyés ;
- sort : tri des résultats (potentiellement sur plusieurs champs) ;
- start : borne de départ pour limiter le jeu de résultats - permet la pagination des résultats ;
- rows : nombre maximum de résultats renvoyés ;
- fq : « filter query », similaire à la clause WHERE du langage SQL - peut contenir plusieurs conditions séparées des mots clefs AND ou OR, ou bien peut apparaître plusieurs fois.
VI-C-1. Paramètre « q »▲
Ce paramètre a deux usages :
- soit en chaîne libre, c’est-à -dire une recherche sur le champ par défaut : « q=solr » ;
- soit en champ spécifique : « q=productNameEnSearch:solr ».
Il est possible de filtrer les résultats de la requête en utilisant la variante « q=champ:valeur » et les opérateurs, par exemple : « q=productNameEnSearch:solr AND manufacturerNameEnSearch:apache », mais nous verrons plus loin qu’il y a d’autres méthodes pour filtrer les résultats.
Il est également possible d’utiliser des couples de parenthèses pour appliquer les opérateurs, par exemple : « q=manufacturerNameEnSearch:apache AND (productNameFrSearch:recherche OR productNameEnSearch:search) ».
VI-C-2. Paramètre « fl »▲
Il permet de ne renvoyer qu’un sous-ensemble des champs définis dans schema.xml pour ce document. S’il n’est pas renseigné, Solr considère qu’il faut renvoyer tous les champs (excepté score, car il ne fait pas partie du document).
Pour définir la liste des champs à renvoyer, il faut séparer les noms de champs par une virgule : « ?q=solr&fl=score,allEnSearch,allFrSearch » ou « ?q=solr&fl=score,* ».
VI-C-3. Paramètre « sort »▲
Le paramètre « sort » s’applique de la manière suivante : sort=<fieldName> <direction>[,<fieldName> <direction>]...
La direction est soit « asc », soit « desc ».
Solr ne peut trier les résultats que dans les conditions suivantes :
- il s’agit du pseudo champ « score » ;
- il s’agit d’une fonction ne renvoyant qu’un seul résultat par document ;
- il s’agit d’un champ qui est à la fois indexé (indexed="true") et non multivalué (multiValued="false"), pourvu que son fieldType soit non tokenisé ou que son fieldType/analyzer/tokenizer utilise KeywordTokenizer.
Comme on peut le voir, effectuer un tri sur un champ de type texte est sujet à diverses contraintes. Si vous vous trouvez dans cette situation, la solution est généralement d’utiliser copyField pour avoir plusieurs variantes du champ, dont une soit compatible avec le paramètre sort.
VI-C-4. Paramètres « start » et « rows »▲
Ces paramètres sont similaires aux clauses SQL LIMIT, OFFSET et TOP proposées par certains SGBD.
« start » permet de limiter le jeu de résultats par décalage du début. Par exemple, si ma requête « ?q=solr » me renvoie 10 résultats, je peux demander « ?q=solr&start=3 » pour que le jeu de résultats en contienne 4 de moins. Comme souvent en informatique, ce paramètre commence à la valeur zéro.
« rows » permet de limiter le jeu de résultats par un retour prématuré. Par exemple, si ma requête « ?q=solr » me renvoie 10 résultats, je peux demander « ?q=solr&rows=6 » pour ne récupérer que les 6 premiers.
VI-C-5. Paramètre « fq »▲
Il permet de filtrer le jeu de résultats et, bien qu’il puisse sembler redondant, il évite de devoir construire un paramètre « q » compliqué.
Contrairement au paramètre « q », il est possible de préciser plusieurs fois le paramètre « fq » dans la même requête : « ?q=solr&fq=productNameFrSearch:recherche OR productNameEnSearch:search ».
Une différence majeure avec le paramètre « q » est que le paramètre « fq » n’influence pas le score des résultats.
Comparez : http://localhost:8080/solr/produits/select?q=solr%20AND%20%28productNameFrSearch:recherche%20OR%20productNameEnSearch:search%29&fl=score,uuid
Avec : http://localhost:8080/solr/produits/select?q=solr&fq=productNameFrSearch:recherche%20OR%20productNameEnSearch:search&fl=score,uuid
VI-C-6. Autres paramètres▲
Je vous laisse découvrir les autres paramètres de SearchHandlerSolr: SearchHandler et de CommonQueryParametersSolr: CommonQueryParameters, puis les paramètres de chacun des composants que vous allez utiliser.