Projet

Général

Profil

Actions

Anomalie #18657

fermé

ANALYSE - Indexation full text partielle

Ajouté par Nicolas LE BOZEC il y a environ 3 ans. Mis à jour il y a presque 2 ans.

Statut:
R&D - Terminé
Priorité:
1-Majeur
Assigné à:
-
Version cible:
Début:
24/09/2021
Echéance:

Description

Bonjour,

Suite à un problème qu'un client a eu, il a produit un fix qui permet de prendre en compte le "°" dans le normalize.

Réponse client :
Bonjour,

Il y a quelques mois nous avions ouvert ce ticket #13416 sur un problème d'indexation/recherche full text de notre version 18.10 en production sans que ce souci ne parvienne à être résolu.
Désormais notre cible de déploiement à court terme est la version 20.03.22 qui présente elle-aussi un problème d'indexation full text, nous pensons préférable de ne pas chercher à savoir s'il s'agit du même que sur la 18.10 étant donné les différences dans les modes d'indexation entre les deux versions (script avec cron pour l'une, à la volée pour l'autre).

Le problème tel qu'il se présente sur la 20.03 est le suivant : les contenus de certains courriers (pdf et formats pris en charge) sont correctement indexés et par la suite cherchable via le full text, tandis que d'autres ne semblent pas indexés, sans qu'une raison claire ne se dégage sur l'origine de cette différence.

Suite à un debug assez long j'ai pu réunir quelques informations sur ce comportement qui, je le précise, ne génère aucune erreur (que ce soit au niveau de php lui même, dans les logs techniques ou autre).

Un cas de test qui permet de reproduire le problème est lié au deux fichiers ci-joint (OK.pdf et KO.pdf). Le contenu du fichier OK.pdf est correctement indexé (il n'y a pas grand chose), tandis que le contenu de KO.pdf n'est pas indexé.

Le cas de ces fichiers étant reproductible je me suis mis dans la situation de test suivante : suppression des fichiers de l'index situés dans docservers/indexes/letterbox_coll afin de partir d'un index vierge.
Je crée deux nouveaux courriers successivement, l'un avec OK.pdf en pièce principale et l'autre avec KO.pdf en pièce principale.

A chaque création j'ai greffé un bout de debug sur le fichier src/app/convert/controllers/FullTextController.php au niveau des lignes 103 à 109 :

$doc = new \Zend_Search_Lucene_Document();

$doc->addField(\Zend_Search_Lucene_Field::UnIndexed('Id', (integer)$args['resId']));
$doc->addField(\Zend_Search_Lucene_Field::UnStored('contents', $fileContent));
// début debug MTE
echo var_dump(serialize($doc));
// fin debug MTE
$index->addDocument($doc);
$index->commit();

Cela m'a permis de vérifier que le texte des deux documents est bien détecté et que la création d'un document Zend Search Lucene à partir de cela se passe correctement, ci-dessus le contenu sérialisé de ces documents :

OK.pdf :

O:27:"Zend_Search_Lucene_Document":2:{s:10:"*_fields";a:2:{s:2:"Id";O:24:"Zend_Search_Lucene_Field":9:{s:4:"name";s:2:"Id";s:5:"value";i:217072;s:8:"isStored";b:1;s:9:"isIndexed";b:0;s:11:"isTokenized";b:0;s:8:"isBinary";b:0;s:15:"storeTermVector";b:0;s:5:"boost";d:1;s:8:"encoding";s:0:"";}s:8:"contents";O:24:"Zend_Search_Lucene_Field":9:{s:4:"name";s:8:"contents";s:5:"value";s:32:"courrier arrivee page1 page page";s:8:"isStored";b:0;s:9:"isIndexed";b:1;s:11:"isTokenized";b:1;s:8:"isBinary";b:0;s:15:"storeTermVector";b:0;s:5:"boost";d:1;s:8:"encoding";s:0:"";}}s:5:"boost";d:1;}

KO.pdf :

O:27:"Zend_Search_Lucene_Document":2:{s:10:"*_fields";a:2:{s:2:"Id";O:24:"Zend_Search_Lucene_Field":9:{s:4:"name";s:2:"Id";s:5:"value";i:217073;s:8:"isStored";b:1;s:9:"isIndexed";b:0;s:11:"isTokenized";b:0;s:8:"isBinary";b:0;s:15:"storeTermVector";b:0;s:5:"boost";d:1;s:8:"encoding";s:0:"";}s:8:"contents";O:24:"Zend_Search_Lucene_Field":9:{s:4:"name";s:8:"contents";s:5:"value";s:1385:"cplus gps dpnm3 pnm snum developpement durable gouv pour bcpr scan demo prod question ecrite n° 40402 monsieur dominique potier depute meurthe moselle 2021 page 5967 question dominique potier interroge mme ministre deleguee aupres ministre transition ecologique chargee logement sur mise ruvre dispositif aide logement des moins ans decide fevrier 2021 mai 2021 une enquete commandee aupres institut sondage ipsos realisee mars 2021 sur echantillon 000 personnes agees ans revelait jeune sur deux avait rencontre des difficultes cours derniere annee pour payer les charges liees son logement chiffre temoigne lui seul necessite des dispositifs aide logement destination des jeunes image subvention 000 euros mise place fevrier 2021 pour accompagner les salaries moins ans les alternants dans installation leur logement neanmoins apres quelques jours seulement nombre dossiers enregistres dans plateforme depasse limite enveloppe financiere consacree cette subvention jour faute moyens suffisants alloues dispositif est donc impossible pour nombreux jeunes pretendre cette aide alors meme ils seraient eligibles est pourquoi souhaite interroger pour savoir une hausse des moyens consacres cette aide pourrait etre envisagee afin que toutes les personnes eligibles puissent beneficier independamment leur ordre arrivee comme est ordinaire cas pour les aides prestations sociales reponse";s:8:"isStored";b:0;s:9:"isIndexed";b:1;s:11:"isTokenized";b:1;s:8:"isBinary";b:0;s:15:"storeTermVector";b:0;s:5:"boost";d:1;s:8:"encoding";s:0:"";}}s:5:"boost";d:1;}

Afin d'être sûr que ces objets documents arrivent bien dans l'index, j'ai mis un autre bout de debug au niveau de la recherche, dans le fichier apps/maarch_entreprise/indexing_searching/search_adv_result.php sur les lignes 340 et 341 :

$index = Zend_Search_Lucene::open($path_to_lucene_index);
// début debug MTE
echo var_dump($index->getDocument(0));
echo var_dump($index->getDocument(1));
echo var_dump($index->terms());
// fin debug MTE
$hits = $index->find(urldecode($fulltext_request));

Cela permet de constater plusieurs choses :

  • le document OK.pdf arrive bien dans l'index, il apparaît avec son resId,
  • le document KO.pdf arrive bien dans l'index, il apparaît avec son resId,
  • les seuls termes indexés (et donc utilisés pour la recherche) sont ceux de OK.pdf, aucun terme de KO.pdf n'apparaît,

Ce dernier point me paraît être le cœur du problème. Je n'ai pas d'explication pour l'instant sur cette différence de traitement entre les deux pdfs, ce qui revient à dire entre les deux strings de texte détecté.
La seule différence notable que je vois est leurs longueurs, est-il possible qu'il y ait une limite d'indexation basse ou un paramétrage qui joue là dessus ?

Pour information tous nos tests se font sur PHP 7.4.

Je vous remercie d'avance pour votre éclairage sur ce point bloquant pour nous : une grande plus-value de Maarch Courrier vis-à-vis des utilisateurs étant sa recherche plein texte.

Bien cordialement,


Fichiers

OK.pdf (30,6 ko) OK.pdf Florent CAPPON, 24/09/2021 09:11
KO.pdf (90,8 ko) KO.pdf Florent CAPPON, 24/09/2021 09:11

Demandes liées 3 (0 ouverte3 fermées)

Lié à Backlog Courrier - Anomalie #18760: Recherche avancée : le critère "Plein texte" ne retourne pas les résultats attendusR&D - Terminé10/11/2021Actions
Lié à Backlog Courrier - Anomalie #18983: Ignorer les espaces insécables dans la recherche fulltextR&D - TerminéMathieu PIONNIER08/12/2021Actions
Lié à Backlog Courrier - Anomalie #19022: Recherche plein texte KO : Too many open filesR&D - TerminéEtienne FAMERY10/12/202127/12/2021Actions
Actions

Formats disponibles : Atom PDF