Project

General

Profile

Anomalie #18657

ANALYSE - Indexation full text partielle

Added by Nicolas LE BOZEC 8 months ago. Updated 6 months ago.

Status:
Développé / Analysé (S)
Priority:
1-Majeur
Assignee:
-
Target version:
Start date:
09/24/2021
Due date:
Tags Courrier:
20.03.24, 20.10.16, 21.03.13

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,

OK.pdf (30.6 KB) OK.pdf Florent CAPPON, 09/24/2021 09:11 AM
KO.pdf (90.8 KB) KO.pdf Florent CAPPON, 09/24/2021 09:11 AM

Related issues

Related to Backlog Courrier - Anomalie #18760: Recherche avancée : le critère "Plein texte" ne retourne pas les résultats attendusDéveloppé / Analysé (S)2021-11-10
Related to Backlog Courrier - Anomalie #18983: Ignorer les espaces insécables dans la recherche fulltextDéveloppé / Analysé (S)2021-12-08
Related to Backlog Courrier - Anomalie #19022: Recherche plein texte KO : Too many open filesDéveloppé / Analysé (S)2021-12-102021-12-27

History

#2 Updated by Emmanuel DILLARD 8 months ago

  • Subject changed from Contribution MTES-MCT [Indexation full text partielle] to REVIEW - Contribution [Indexation full text partielle]

#3 Updated by Madina Makhmutova 8 months ago

  • Due date deleted (12/01/2021)
  • Status changed from A qualifier to A étudier

#4 Updated by Emmanuel DILLARD 7 months ago

  • Tracker changed from Fonctionnalité to Anomalie
  • Subject changed from REVIEW - Contribution [Indexation full text partielle] to Indexation full text partielle
  • Due date set to 11/22/2021
  • Priority changed from 2-Sérieux to 1-Majeur

#5 Updated by Emmanuel DILLARD 7 months ago

  • Related to Anomalie #18760: Recherche avancée : le critère "Plein texte" ne retourne pas les résultats attendus added

#6 Updated by Emmanuel DILLARD 7 months ago

  • Status changed from A étudier to Prêt à développer

#7 Updated by Emmanuel DILLARD 7 months ago

  • Due date deleted (11/22/2021)

#8 Updated by Emmanuel DILLARD 7 months ago

  • Subject changed from Indexation full text partielle to ANALYSE - Indexation full text partielle
  • Status changed from Prêt à développer to En cours de dev (S)

#9 Updated by Emmanuel DILLARD 7 months ago

  • Due date set to 12/14/2021

#10 Updated by Emmanuel DILLARD 7 months ago

  • Due date changed from 12/14/2021 to 12/08/2021

#11 Updated by Quentin RIBAC 7 months ago

  • Status changed from En cours de dev (S) to A tester (S)

#12 Updated by GIT LAB 7 months ago

Commit ajouté sur la branche fix/18657/20.10 de MaarchCourrier par Quentin RIBAC quentin.ribac@xelians.fr
FIX #18657 TIME 0:30 ignoring short words in fulltext search
https://labs.maarch.org/maarch/MaarchCourrier/commit/b0ae28d966dfeff918fcbacf84c83c31385e849f

#13 Updated by GIT LAB 7 months ago

Commit ajouté sur la branche fix/18657/20.10 de MaarchCourrier par Quentin RIBAC quentin.ribac@xelians.fr
FIX #18657 TIME 0:08 squeezing spaces in fulltext result
https://labs.maarch.org/maarch/MaarchCourrier/commit/1a9a13833d66ae9e386ec3a12832a574eee06b79

#14 Updated by GIT LAB 7 months ago

Commit ajouté sur la branche fix/18657/21.03 de MaarchCourrier par Quentin RIBAC quentin.ribac@xelians.fr
FIX #18657 TIME 0:08 fulltext search: ignoring shorter words (<3 characters) and squeezing spaces
https://labs.maarch.org/maarch/MaarchCourrier/commit/a46cb54cded9827f2738712305e6b90ecd9d9959

#16 Updated by GIT LAB 7 months ago

Commit ajouté sur la branche fix/18657/develop de MaarchCourrier par Quentin RIBAC quentin.ribac@xelians.fr
FIX #18657 TIME 0:15 fulltext: indexing with UTF-8; searching without excess space and shorter words
https://labs.maarch.org/maarch/MaarchCourrier/commit/ccb50ae95b634bf2414513fbc3e77d866cc3b8c6

#17 Updated by GIT LAB 7 months ago

Commit ajouté sur la branche fix/18657/20.10 de MaarchCourrier par Quentin RIBAC quentin.ribac@xelians.fr
FIX #18657 TIME 0:20 fulltext: search with or without accents
https://labs.maarch.org/maarch/MaarchCourrier/commit/7343d89bba7a86a49d71dfc3df5416caade01c0e

#18 Updated by GIT LAB 7 months ago

Commit ajouté sur la branche fix/18657/develop de MaarchCourrier par Quentin RIBAC quentin.ribac@xelians.fr
FIX #18657 TIME 0:05 fulltext: searching with or without accents
https://labs.maarch.org/maarch/MaarchCourrier/commit/fb0d6e8c465e0151d132c768d1bc2455eacccc07

#19 Updated by GIT LAB 7 months ago

Commit ajouté sur la branche fix/18657/21.03 de MaarchCourrier par Quentin RIBAC quentin.ribac@xelians.fr
FIX #18657 TIME 0:05 fulltext: searching with or without accents
https://labs.maarch.org/maarch/MaarchCourrier/commit/3adfbf95e855435667a225e7e033e25a16dc00d9

#20 Updated by GIT LAB 7 months ago

Commit ajouté sur la branche fix/18657/20.03 de MaarchCourrier
FIX #18657 TIME 0:10 fulltext: indexing with utf-8; search with or without accents, ignoring shorter words
https://labs.maarch.org/maarch/MaarchCourrier/commit/9cd9fb9bcc24b5fe1d60f2b2dbd518d5688c9b6d

#22 Updated by Quentin RIBAC 7 months ago

  • Tags Courrier 20.10.16 added

#23 Updated by Ines MKACHER 7 months ago

  • Target version changed from 20.03 (Restreint) to 20.10 (Actif)

#24 Updated by Ines MKACHER 7 months ago

  • Related to Anomalie #18983: Ignorer les espaces insécables dans la recherche fulltext added

#25 Updated by Ines MKACHER 7 months ago

  • Related to Anomalie #19022: Recherche plein texte KO : Too many open files added

#26 Updated by GIT LAB 7 months ago

#27 Updated by Ines MKACHER 7 months ago

  • Due date deleted (12/08/2021)
  • Status changed from A tester (S) to Développé / Analysé (S)
  • Tags Courrier 20.03.23, 21.03.13 added

#29 Updated by Emmanuel DILLARD 6 months ago

  • Tags Courrier 20.03.24 added
  • Tags Courrier deleted (20.03.23)

Also available in: Atom PDF