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

Mis à jour par Emmanuel DILLARD il y a environ 3 ans

  • Sujet changé de Contribution MTES-MCT [Indexation full text partielle] à REVIEW - Contribution [Indexation full text partielle]

Mis à jour par Madina Makhmutova il y a environ 3 ans

  • Echéance 01/12/2021 supprimé
  • Statut changé de A qualifier à R&D - A étudier

Mis à jour par Emmanuel DILLARD il y a environ 3 ans

  • Tracker changé de Fonctionnalité à Anomalie
  • Sujet changé de REVIEW - Contribution [Indexation full text partielle] à Indexation full text partielle
  • Echéance mis à 22/11/2021
  • Priorité changé de 2-Sérieux à 1-Majeur

Mis à jour par Emmanuel DILLARD il y a environ 3 ans

  • Lié à Anomalie #18760: Recherche avancée : le critère "Plein texte" ne retourne pas les résultats attendus ajouté

Mis à jour par Emmanuel DILLARD il y a environ 3 ans

  • Statut changé de R&D - A étudier à R&D - A planifier

Mis à jour par Emmanuel DILLARD il y a environ 3 ans

  • Echéance 22/11/2021 supprimé

Mis à jour par Emmanuel DILLARD il y a presque 3 ans

  • Sujet changé de Indexation full text partielle à ANALYSE - Indexation full text partielle
  • Statut changé de R&D - A planifier à R&D - En cours

Mis à jour par Emmanuel DILLARD il y a presque 3 ans

  • Echéance mis à 14/12/2021

Mis à jour par Emmanuel DILLARD il y a presque 3 ans

  • Echéance changé de 14/12/2021 à 08/12/2021

Mis à jour par Quentin RIBAC il y a presque 3 ans

  • Statut changé de R&D - En cours à R&D - En test

Mis à jour par GIT LAB il y a presque 3 ans

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

Mis à jour par GIT LAB il y a presque 3 ans

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

Mis à jour par GIT LAB il y a presque 3 ans

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

Mis à jour par GIT LAB il y a presque 3 ans

Mis à jour par GIT LAB il y a presque 3 ans

Commit ajouté sur la branche fix/18657/develop de MaarchCourrier par Quentin RIBAC
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

Mis à jour par GIT LAB il y a presque 3 ans

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

Mis à jour par GIT LAB il y a presque 3 ans

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

Mis à jour par GIT LAB il y a presque 3 ans

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

Mis à jour par GIT LAB il y a presque 3 ans

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

Mis à jour par GIT LAB il y a presque 3 ans

Mis à jour par Ines MKACHER il y a presque 3 ans

  • Version cible changé de 20.03 (Sécurité) à 20.10

Mis à jour par Ines MKACHER il y a presque 3 ans

  • Lié à Anomalie #18983: Ignorer les espaces insécables dans la recherche fulltext ajouté

Mis à jour par Ines MKACHER il y a presque 3 ans

  • Lié à Anomalie #19022: Recherche plein texte KO : Too many open files ajouté

Mis à jour par GIT LAB il y a presque 3 ans

Mis à jour par Ines MKACHER il y a presque 3 ans

  • Echéance 08/12/2021 supprimé
  • Statut changé de R&D - En test à R&D - Terminé

Mis à jour par GIT LAB il y a presque 3 ans

Mis à jour par Emmanuel DILLARD il y a presque 2 ans

MAJ Branche Develop->2301

Actions

Formats disponibles : Atom PDF