utilisant un peu extraire_documents pour faire de l’indexation de documents dans un moteur de recherche, je me fais la reflexion qu’actuellement chaque indexation provoque la conversion du fichier en texte, même si le fichier initial n’a pas changé.
De plus le texte extrait est bien utilisé pour indexer le document dans le moteur de recherche, mais n’est plus disponible ensuite nulle part.
Je propose donc que le plugin extraire_documents ajoute un champs texte à la table SQL spip_documents, et y stocke le texte extrait depuis le fichier décrit par l’enregistrement de id_document.
On y associerai de plus un champ du genre date_texte ou date_extraction, permettant de vérifier si la dernière extraction est plus récente que le fichier ou non, et si besoin de relancer une nouvelle extraction (dans le cas où le fichier a été modifié/ré-uploadé…)
Ce champ texte agirait donc comme un cache de l’extraction du texte et permettrait en plus d’afficher une #INTRODUCTION issue du contenu extrait (ou d’afficher le #TEXTE pour tout usage que l’on peut imaginer, à commencer par la verification humaine du contenu extrait et indexé).
Des avis, des contre-indications, des contre-propositions ?
(je peux aussi faire ça dans mon coin avec une surcharge de inc_extraire_document() si ça n’emballe pas la foule des utilisateurs !)
Bises
Des avis, des contre-indications, des contre-propositions ?
Tout à fait d'accord : on avait imaginé exactement pareil pour un projet
où il n'était pas forcément possible d'avoir Sphinx et donc pour
permettre de chercher dans les extractions. C'est en fait déjà ce que
fait Fulltext, mais nous on voulait utiliser le plugin plus générique.
Mais on n'a pas eu le projet, et donc bah on l'a jamais fait.
Donc oui, c'est une sorte de report dans Extraire Documents de ce que
fait Fulltext, mais sans le nécessiter
(Et à la fin faudrait peut-être une nouvelle branche de Fulltext qui
vire tout ce qui est extraction et modif de spip_documents et qui ne
fait que l'indexation et recherche SQL).
Le mar. 19 juin 2018 à 18:21, Cerdic <cedric@yterium.com> a écrit :
Hello,
utilisant un peu extraire_documents pour faire de l’indexation de
documents dans un moteur de recherche, je me fais la reflexion
qu’actuellement chaque indexation provoque la conversion du fichier en
texte, même si le fichier initial n’a pas changé.
De plus le texte extrait est bien utilisé pour indexer le document dans le
moteur de recherche, mais n’est plus disponible ensuite nulle part.
Tututut. Il est dispo dans l'indexeur avant ré-indexation (et plus léger a
priori que de taper sur le SGDC). Le seul problème (qui s'en va dans ton
cas de figure), c'est si l'on change la manière d'indexer ce texte. Il
faudrait peut-être une indexation "brut" à côté de l'indexation pour la
recherche pour palier à cela.
Je propose donc que le plugin extraire_documents ajoute un champs texte à
la table SQL spip_documents, et y stocke le texte extrait depuis le fichier
décrit par l’enregistrement de id_document.
le texte alourdit vraiment la base, c'est ce qui ne nous plaisait pas
On y associerai de plus un champ du genre date_texte ou date_extraction,
permettant de vérifier si la dernière extraction est plus récente que le
fichier ou non, et si besoin de relancer une nouvelle extraction (dans le
cas où le fichier a été modifié/ré-uploadé…)
oui ça c'est bien
Ce champ texte agirait donc comme un cache de l’extraction du texte et
permettrait en plus d’afficher une #INTRODUCTION issue du contenu extrait
(ou d’afficher le #TEXTE pour tout usage que l’on peut imaginer, à
commencer par la verification humaine du contenu extrait et indexé).
Des avis, des contre-indications, des contre-propositions ?
A défaut de faire comme ça, on fait un ré-extraire en cas de ré-indexation,
sauf si le fichier du document n'a pas bougé (du coup, du côté indexeur,
pas du côté extraire_documents)
(je peux aussi faire ça dans mon coin avec une surcharge de
inc_extraire_document() si ça n’emballe pas la foule des utilisateurs !)
On 19 juin 2018 à 23:22 +0200, Guy Cesaro <guy.cesaro@gmail.com>, wrote:
Plop
> Le mar. 19 juin 2018 à 18:21, Cerdic <cedric@yterium.com> a écrit :
> > Hello,
> >
> > utilisant un peu extraire_documents pour faire de l’indexation de documents dans un moteur de recherche, je me fais la reflexion qu’actuellement chaque indexation provoque la conversion du fichier en texte, même si le fichier initial n’a pas changé.
> >
> > De plus le texte extrait est bien utilisé pour indexer le document dans le moteur de recherche, mais n’est plus disponible ensuite nulle part.
> Tututut. Il est dispo dans l'indexeur avant ré-indexation (et plus léger a priori que de taper sur le SGDC). Le seul problème (qui s'en va dans ton cas de figure), c'est si l'on change la manière d'indexer ce texte. Il faudrait peut-être une indexation "brut" à côté de l'indexation pour la recherche pour palier à cela.
Hmmm, en fait ça dépend sans doute de ton indexer.
Par exemple avec Sphinx il est bien dispo dans le content, mais agrémenté du titre, du descriptif, des mots clés, des auteurs etc.
Ce qu’on peut faire c’est rendre le stockage en base optionnel désactivable, si pour des raisons de performance tu préfère re-parser le pdf à chaque fois plutot que stocker en base le texte complet. En fait la balance entre les 2 options dépend un peu du nombre de documents dont tu disposes vs le poids des documents etc…
Bon je prends en compte ta remarque et j’essaye de faire quelque chose qui couvre tout !
Bon voila, du coup l’extracteur gère donc seulement la possibilité qu’il y ait un cache contenu avec un hash contenu_filehash
sans présumer de ce tu en feras derrière.
Tu peux ne pas les stocker et ça continue à fonctionner comme avant, ou alors tu stockes contenu et contenu_filehash (dans spip_documents ou dans ton indexer) et tu les fournis dans l’appel de l’extracteur et paf il evite de tourner pour rien quand ton contenu est déjà connu.
Voilà comme ça on peut gérer proprement au niveau de l’indexer le choix de stockage le plus pertinent.
(et moi je m’arrête là pour le code communautaire et je gère le stockage dans spip_documents dans mon code applicatif spécifique)
Bises
--
Cédric
On 20 juin 2018 à 08:37 +0200, Cerdic <cedric@yterium.com>, wrote:
On 19 juin 2018 à 23:22 +0200, Guy Cesaro <guy.cesaro@gmail.com>, wrote:
> Plop
>
> > Le mar. 19 juin 2018 à 18:21, Cerdic <cedric@yterium.com> a écrit :
> > > Hello,
> > >
> > > utilisant un peu extraire_documents pour faire de l’indexation de documents dans un moteur de recherche, je me fais la reflexion qu’actuellement chaque indexation provoque la conversion du fichier en texte, même si le fichier initial n’a pas changé.
> > >
> > > De plus le texte extrait est bien utilisé pour indexer le document dans le moteur de recherche, mais n’est plus disponible ensuite nulle part.
> > Tututut. Il est dispo dans l'indexeur avant ré-indexation (et plus léger a priori que de taper sur le SGDC). Le seul problème (qui s'en va dans ton cas de figure), c'est si l'on change la manière d'indexer ce texte. Il faudrait peut-être une indexation "brut" à côté de l'indexation pour la recherche pour palier à cela.
Hmmm, en fait ça dépend sans doute de ton indexer.
Par exemple avec Sphinx il est bien dispo dans le content, mais agrémenté du titre, du descriptif, des mots clés, des auteurs etc.
Ce qu’on peut faire c’est rendre le stockage en base optionnel désactivable, si pour des raisons de performance tu préfère re-parser le pdf à chaque fois plutot que stocker en base le texte complet. En fait la balance entre les 2 options dépend un peu du nombre de documents dont tu disposes vs le poids des documents etc…
Bon je prends en compte ta remarque et j’essaye de faire quelque chose qui couvre tout !
Ça peut pas être une option directe de ce plugin là, sans rien avoir à
coder ou nécessiter d'autre plugin, de dire "je veux que ce soit gardé
en mémoire dans la table des documents" ?
Car sauf site avec 15000 PDF de 20Mo, et c'est pas tous les jours :p,
c'est plutôt majoritairement une bonne idée ton truc de le garder dans
spip_documents
A priori si on doit le mettre quelque part c’est plutot dans le plugin indexer, car de ce que je comprends de la remarque de Guy c’est que certains indexeur stockent déjà ce contenu accessible, auquel cas c’est redondant et inutile de le stocker aussi dans spip_documents.
--
Cédric
On 20 juin 2018 à 14:48 +0200, RastaPopoulos <rastapopoulos@spip.org>, wrote:
Ça peut pas être une option directe de ce plugin là, sans rien avoir à
coder ou nécessiter d'autre plugin, de dire "je veux que ce soit gardé
en mémoire dans la table des documents" ?
Car sauf site avec 15000 PDF de 20Mo, et c'est pas tous les jours :p,
c'est plutôt majoritairement une bonne idée ton truc de le garder dans
spip_documents
