Intégration Solr dans ezPublish mal configurée

Lors d’une mission récente, j’ai du m’intérresser à la configuration Solr par défaut fournie avec le plugin ezFind 2.3. Les 2 fichiers de configuration Solr principaux sont solrconfig.xml et schema.xml. J’ai donc constaté que les fichiers fournis avec le plugin ne sont pas configurés de façon optimum et c’est peut de le dire. Après vérification dans le code source du ezFind 2.7 (la dernière version du plugin), aucune amélioration n’est constaté. Voici les principaux problèmes constatés.

Dans le fichier schema.xml est définie le type “text” utilisé pour la totalité du contenu textuel de ezPublish

1/ la totalité des champs textuels sont copiés dans le champ “ezf_df_text”

2/ le champ “ezf_df_text” est de type “text”

3/ le type “text” est définie ainsi

Voici les commentaires que l’on peut faire sur la définition de ce type.

La tokenization utilise le “WhitespaceTokenizer”

Le texte suivant “Voici le principal problème à cause de ces fichiers, mais il y en a d’autres.” est donc tokenizé comme ceci en se basant uniquement sur les espaces :

“Voici”, “le”, “principal”, “problème,”, “à”, “cause”, “de”, “ces”, “fichiers,”, “mais”, “il”, “y”, “en”, “aura”, “d’autres.”

Problème 1: On constate qu’il n’y a pas de tokenization sur les ponctuations ou les apostrophes. On obtient entre autres les tokens suivants : “problème,”, “à”, “fichiers,” et “d’autres.”

Le filtre suivant lors de l’indexation traite les mots-vides et doit en principe supprimer les tokens tels que “Voici”, “à”, “le”, “de”, “d”, “il”, “mais”, … et peut être même “autres” si on le considère comme un mot vide.

Problème 2: La conséquence de l’utilisation du “WhitespaceTokenizer” est que ni “d”, ni “autres” ne sont supprimés des tokens car ils ne sont pas des tokens à part entière.

Le fitre suivant normalise les caractères accentués en leurs équivalents non accentués

Problème 3: La position de ce filtre après le traitement des mots-vide fait que le token “à” n’est pas supprimé sauf si le fichier de mots-vide contient les 2 termes “a” et “à”.

Le filtre suivant normalise les caractères majuscules en minuscules.

Problème 4: La position de ce filtre après le traitement des mots-vide fait que le token “Voici” n’est pas supprimé.

Problème 5: L’utilisation du tokenizer “WhitespaceTokenizer” fait que dans l’index, on trouve le token “fichiers,”. Ce terme ne sera jamais cherché avec la virgule dans une requête donc il ne permettra pas de retrouver le document.

En fait, ce n’est pas tout à fait vrai car le filtre “WordDelimiterFilter” va traiter ce problème.

En effet, avec ce filtre, les tokens “fichiers,” et “d’autres.” deviennent “fichiers”, “d”, “autres” et “dautres”. Le cas de “fichiers,” s’en trouve bien traité, mais je ne pense pas que ce soit l’objectif voulu à l’origine par l’auteur de ce parametrage car ce filtre a un tout autre but. De plus, les tokens “d” et “dautres” n’ont rien à faire dans l’index. le premier est un mot vide et le second n’est pas un mot du tout.

Le bon paramètrage pour l’indexation est en fait le suivant :

On utilise le “StandardTokenizerFactory” pour tokenizer sur tout élément qui est séparateur de mots et on place immédiatement après les filtres qui servent à normaliser les caractères accentués et les majuscules. Ainsi :

  • le traitement des mots vides fonctionne bien pour “Voici et “à”
  • “d” et “dautres’ ne sont pas indexés

Pour la recherche, les problèmes sont les même auxquels s’ajoute celui du traitement des synonymes.

Problème 6: On constate que le non traitement des accents et des majuscules avant celui de la synonymie fait que des termes de requêtes saisie avec accents et/ou majuscules ne seront jamais associés à leurs synonymes.

Le bon paramètrage pour la recherche est en fait le suivant :

En ce qui concerne le fichier solrconfig.xml, j’ai, 2 commentaires à faire. Lors de la recherche, ezFind utilise un requestHandler nommé “ezpublish”.

Ce request handler définie l’utilisation du parser de requêtes “edismax” (“dismax” dans ezFind 2.3) et fait porter les recherches sur le champ texte global “ezf_df_text”.

Commentaire 1: Il est dommage de ne pas profiter des capacités du parser edismax pour faire porter également la recherche sur le titre des documents avec une pondération plus forte sur ce titre. Le paramètrev “qf” pourrait par exemple être ceci :

Commentaire 2: Un bug existe dans ezFind 2.3 et a été corrigé dans les dernières versions du plugin mais je ne sais pas exactement à partir de quelle version. Il s’agit de l’utilisation du paramètre “mm”.

Le détail de ce bug et de sa correction est indiqué dans cette page https://github.com/ezsystems/ezfind/pull/58
Il s’agit d’un problème lié aux mots-vides qui fait qu’une requête comportant un ou plusieurs mots-vides peut ne pas retourner tous les documents qui le devraient, voir ne rien retourner du tout. Je vous encourage donc à vérifier que votre version de ezFind corrige ce problème.

3 Commentairess

  1. Damien 23 mars 2013
  2. Gilles 26 mars 2013
  3. admin 26 mars 2013

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *