Comment ça marche

L’intégration de l’indexation Solr avec Texpress fournit une méthode alternative mais compatible de recherche de documents. Dans cette section, l’intégration est examinée en détail et fournit des informations utiles pour ceux qui souhaitent interagir directement avec les index Solr. Une telle interaction peut être utile pour les systèmes basés sur le Web.

Lorsque le schéma d’une table Texpress est enregistré à l’aide de texdesign, le schéma Solr équivalent est généré. Le schéma Texpress se trouve dans le fichier :

data/table/ins

qui contient le formulaire d’insertion ; et le schéma Solr se trouve dans le fichier :

solr/table/solr/conf/schema.xml

Le schéma Solr est composé de deux sections. Le premier contient les types de champs utilisés pour définir les types d’indexation à appliquer aux champs. Les types de champs sont inclus dans la balise XML <fieldType>. Par exemple :

<fieldType name='string' class='solr.StrField' stored='false' />

<fieldType name='strings' class='solr.StrField' stored='false' multiValued='true' />

<fieldType name='int' class='solr.LongPointField' stored='false' />

<fieldType name='ints' class='solr.LongPointField' stored='false' multiValued='true' />

La deuxième section énumère les index du champ et sont définis à l’aide de la balise XML <field>. Par exemple :

<field name='irn_value' type='value' />

<field name='SummaryData_text' type='text' />

<field name='SummaryData_phonetic' type='phonetic' />

<field name='ExtendedData_text' type='text' />

Le fichier de schéma Solr est généré automatiquement et ne doit pas être modifié manuellement. Il est très important que le schéma de Texpress et le schéma de Solr soient synchronisés.

Les types de champs Solr déclarent le type d’index à créer pour un certain type de données. Chaque type de champ correspond à un type d’index Texpress. Le tableau ci-dessous montre la correspondance entre le type de champ Solr et le type d’index Texpress correspondant :

Type de champ Solr	Type d’indexation Texpress	Commentaires
`text`	`HASH (word)`	Index basé sur les mots où chaque mot et chaque symbole est indexé.
`texts`	`HASH (word)`	Identique à `text`, mais utilisé pour les champs de texte à valeurs multiples.
`phonetic`	`PHONETIC (word)`	Index basé sur les mots où la phonétique (son similaire) de chaque mot et symbole est indexée.
`phonetics`	`PHONETIC (word)`	Identique à `phonetic`, mais utilisé pour les champs de texte à valeurs multiples.
`stem`	`STEM (word)`	Index basé sur les mots où le radical (mot de base) de chaque mot et symbole est indexé.
`stems`	`STEM (word)`	Identique à `stem`, mais utilisé pour les champs de texte à valeurs multiples.
`value`	`RANGE`	La valeur exacte pour les champs de type plage et tuple. Les champs de portée sont les champs de date, d’heure, de latitude et de longitude. Les champs tuple sont des éléments de la bibliothèque Texpress comportant plusieurs champs ou éléments clés.
`values`	`RANGE`	Identique à `value`, mais utilisé pour les champs de texte à valeurs multiples.
`lower`	`RANGE`	La valeur minimale d’une valeur partielle (par exemple, Jan 2020 a une valeur minimale de 1er jan 2020).
`lowers`	`RANGE`	Identique à `lower`, mais utilisé pour les champs de texte à valeurs multiples.
`upper`	`RANGE`	La valeur maximale d’une valeur partielle (par exemple, Jan 2020 a une valeur maximale de 31 Jan 2020).
`uppers`	`RANGE`	Identique à `upper`, mais utilisé pour les champs de texte à valeurs multiples.
`string`	`HASH (string)`	Index basé sur les termes où la valeur complète est indexée comme un seul terme.
`strings`	`HASH (string)`	Identique à `string`, mais utilisé pour les champs de texte à valeurs multiples.
`int`	`HASH (integer)`	Index basé sur un integer. Prise en charge de la recherche par valeur exacte et par plage.
`ints`	`HASH (integer)`	Identique à `int`, mais utilisé pour les champs de texte à valeurs multiples.
`real`	`HASH (float)`	Index basé sur un nombre à virgule flottante. Prise en charge de la recherche par valeur exacte et par plage.
`reals`	`HASH (float)`	Identique à `real`, mais utilisé pour les champs de texte à valeurs multiples.
`null`	`NULL`	Index utilisé pour rechercher si un champ est vide ou non vide.

Chaque champ du schéma Texpress dont l’indexation est activée aura une entrée dans le schéma Solr. Pour chaque type d’index Texpress activé, une valeur de champ Solr correspondante du même type d’index est générée. Le nom donné à l’index Solr est le nom du champ, suivi d’un trait bas et du type de champ Solr. Par exemple, le champ NamTitle du module eparties possède les types d’index Texpress suivants activés :

HASH (word)
STEM
NULL

Les définitions des champs Solr correspondants sont les suivantes :

NamTitle_text
NamTitle_stem
NamTitle_null

Lorsqu’un enregistrement est sauvegardé, Texpress traite chaque champ un par un. Pour chaque champ, il génère les termes pour chaque type d’index activé. Lorsque l’indexation Solr est activée, les termes sont stockés dans le champ correspondant au type d’index. Par exemple, si un enregistrement avait la valeur Doctor dans le champ NamTitle, les valeurs suivantes seraient ajoutées à chaque champ Solr :

Champ	Valeur
`NamTitle_text`	`doctor`
`NamTitle_stem`	`doct`
`NamTitle_null`	`false`

Le terme Doctor est converti en minuscules par Texpress de sorte que la recherche non sensible à la casse est la valeur par défaut.

Lorsqu’une recherche est effectuée sur une table, un contrôle de son type d’indexation est effectué. Si l’indexation Solr est activée, le moteur de recherche génère une requête Solr sur l’index requis fournissant le terme de la requête. Par exemple, si une recherche est effectuée sur eparties pour les enregistrements dont le champ Titre (NamTitle) contient la valeur Doctor, la requête Solr NamTitle_text:doctor est générée et envoyée à Solr pour traitement. Solr renvoie une liste d’écarts d’enregistrements correspondant à la requête fournie. Les écarts sont ajoutés à la liste des enregistrements correspondants.

Afin de réduire la charge d’indexation, les termes de la requête générés par Texpress sont ajoutés aux index Solr et ne sont pas stockés en tant que données. Les termes de la requête ne peuvent pas être affichés, mais seulement recherchés. Cette approche permet d’éviter la surcharge liée à la sauvegarde des valeurs indexées pour chaque enregistrement. De plus, les données complètes de l’enregistrement ne sont pas stockées, mais seulement l’écart dans le fichier de données Texpress où se trouve l’enregistrement. La combinaison de ces deux optimisations permet de réduire considérablement la charge d’indexation. Par exemple, la taille de l’indexation d’un fichier de données de 2 Go pour la table eaudit à l’aide de l’indexation Texpress est de 3,7 Go, alors que la taille de l’indexation Solr est de 630 Mo (0,6 Go). En termes de ratio, l’indexation Texpress est dans ce cas plus de six fois plus importante que l’indexation Solr.

Lorsque l’option solrdata est activée, les index Solr contiennent également un champ appelé _data_. Ce champ n’est pas utilisé par EMu, mais il est disponible pour les applications tierces qui effectuent des recherches directement dans Solr. La valeur du champ est une chaîne JSON contenant une représentation JSON de l’enregistrement indexé. Si le champ _data_ doit être récupéré, le paramètre fl (liste de champs) dans Solr doit contenir _data_:[json] pour garantir que le champ de chaîne _data_ est traduit en JSON lui-même.

L’enregistrement JSON généré par l’option solrdata contient les données complètes de l’enregistrement. Tous les dossiers sont également conservés. En effet, le système de sécurité d’EMu est contourné si cette option est activée. Lors de l’extraction des données, il convient de s’assurer que les politiques institutionnelles sont respectées avant d’afficher les données. Si l’accès d’un tiers est nécessaire et que le niveau de sécurité des enregistrements est respecté, l’API RESTful d’EMu doit être utilisée.