[SPIP Zone] Plugin Fulltext

Paolo · Mars 14, 2009, 5:43

Bonjour,

J'essaie le plugin Fulltext, et déjà cela m'excite car cela résout deux problèmes que j'avais. Le plus important étant que la recherche SPIP normal ne me retrouve pas certains caractères majuscules « Ę », « Ń », ...
et avec Fulltext, cela marche très bien

En même temps, j'ai des questions (évidemment), et je ne sais pas où les mettre, car le doc est en wiki et sans forum.

Paolo

fil · Mars 14, 2009, 6:20

J'essaie le plugin Fulltext,

déjà !?

et déjà cela m'excite car cela résout deux
problèmes que j'avais.

Le plus important étant que la recherche SPIP normal
ne me retrouve pas certains caractères majuscules « Ę », « Ń », ...
et avec Fulltext, cela marche très bien

excellent. quel est le second problème résolu ?

En même temps, j'ai des questions (évidemment), et je ne sais pas où les
mettre, car le doc est en wiki et sans forum.

Dès qu'on aura un logo on le publie. En attendant tu peux demander ici

-- Fil

fil · Mars 14, 2009, 7:09

2009/3/14 izo Mathieu Drouet <izo@aucuneid.net>:

hello [logo]

et hop !

-- Fil

Paolo · Mars 14, 2009, 7:11

Fil wrote:

déjà !?

Bon. Tu as le don d'imaginer des plugins qui m'intéressent
(Et quand tu te mettras au plugin multiliguisme, je demanderai ton numéro de portable...)

excellent. quel est le second problème résolu ?

Je sais attirer ton attention
C'est simplement d'éviter de recevoir des résultats non-pertinents car la recherche cherchait plus que ce qui était voulu (ex. chercher « Jean » pour trouver des articles sur St. Jean et recevoir une liste d'articles mis-en-ligne par Jean-Christophe...). Avec Fulltext je ne mets pas d'index sur les auteurs et voilà c'est bon.

Dès qu'on aura un logo on le publie. En attendant tu peux demander ici

1) J'ai vu que la page ecrire/?exec=fulltext détecte automatiquement tous les champs "text", y inclus les champs ajoutés avec extras2, pour proposer un index « tout ». Pourquoi ne pas aussi y inclure les CHAR et VARCHAR qui supporte aussi les recherches fulltext : "Full-text indexes can be used only with MyISAM tables, and can be created only for CHAR, VARCHAR, or TEXT columns."
http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html
(je crois que la traduction française de cette page n'est pas entièrement à jour.)

2) Ces indexes peuvent prendre beaucoup de place. Mais je crois que cela ne fera pas gonfler la taille des suavegardes (?)

3) Serait-il intéressant de pouvoir passer à la requête MySQL non seulement la chaîne "AGAINST" mais aussi la chaîne "MATCH" (le(s) nom(s) du/des champ(s) ou doit se faire la recherche).
Si on veut rechercher juste dans les titres par ex., ou dans les cas d'un usage « détourné » de SPIP - pour un carnet d'adresses, de chercher juste dans les noms (prénom, nom, institution) ou juste dans les champs d'adresses (rue, localité, ville). Tout en laissant « tous les champs » comme défaut.

4) J'ai toujours un problème avec le surlignage après recherche de SPIP. J'ai l'impression que le surlignage marche pour les accents « occidentaux », mais non pas pour beaucoup de caractères « spéciaux » d'autres langues. Ça ce n'est déjà plus ce plugin,... mais j'imagine que c'est dans prive/javascript/SearchHighlight.js à partir de la ligne 127 (ou je me trompe ?).

merci,
Paolo

cerdic · Mars 14, 2009, 7:31

Fil a écrit :

2009/3/14 izo Mathieu Drouet <izo@aucuneid.net>:


hello [logo]

et hop !
Fulltext - SPIP-Contrib

Bon je l'ai activé sur contrib, mais :
- idée ne donne aucun résultat
- idee donne 77 résultats
- idée donne 143 résultats
- Plus grave : la recherche prend beaucoup plus de temps qu'avec la recherche standard, et le cpu de mon serveur a grimpé en moyenne de 15% à 40%, avec des pointes à 100% à chaque recherche ...

J'ai désactivé le plugin, et
- la charge cpu est revenue à la normale aussitôt
- Résultats de la recherche - SPIP-Contrib donne 212 résultats...

Cédric

fil · Mars 14, 2009, 9:13

excellent. quel est le second problème résolu ?

Je sais attirer ton attention

ah c'était un piège !

C'est simplement d'éviter de recevoir des résultats non-pertinents car la
recherche cherchait plus que ce qui était voulu (ex. chercher « Jean » pour
trouver des articles sur St. Jean et recevoir une liste d'articles
mis-en-ligne par Jean-Christophe...). Avec Fulltext je ne mets pas d'index
sur les auteurs et voilà c'est bon.

Ca c'était déjà gérable auparavant en supprimant la jointure
articles<->auteurs (mais il fallait coder un pipeline, alors que
maintenant il suffit de ne pas créer d'index ; cela dit note bien
qu'on pourrait imaginer respecter la jointure même en l'absence
d'index... donc ce n'est pas une "feature" stable : tant que ça
marche, profites-en, mais je ne garantis pas que ça n'évoluera pas).

1) J'ai vu que la page ecrire/?exec=fulltext détecte automatiquement tous
les champs "text", y inclus les champs ajoutés avec extras2, pour proposer
un index « tout ». Pourquoi ne pas aussi y inclure les CHAR et VARCHAR qui
supporte aussi les recherches fulltext : "Full-text indexes can be used only
with MyISAM tables, and can be created only for CHAR, VARCHAR, or TEXT
columns."
http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html

Bizarre car précisément au départ je ne faisais aucun test, et j'ai eu
un échec sur un VARCHAR, à savoir le champ login de spip_auteurs.

2) Ces indexes peuvent prendre beaucoup de place.

D'après mes tests environ 2/3 de la taille de la table originale ;
c'est beaucoup moins que ce qu'on faisait autrefois avec
spip_index_dico etc.

Mais je crois que cela ne fera pas gonfler la taille des suavegardes (?)

Non, en effet : ni des sauvegardes SPIP, ni même des dump MySQL ou phpMyAdmin

3) Serait-il intéressant de pouvoir passer à la requête MySQL non seulement
la chaîne "AGAINST" mais aussi la chaîne "MATCH" (le(s) nom(s) du/des
champ(s) ou doit se faire la recherche).

Le problème est qu'il faut qu'un index existe pour exactement cette
liste de champs. Autrmeent dit si tu as un index `titre` et un index
`tout`, tu ne peux pas chercher sur `surtitre`, même s'il fait partie
de `tout` : tu peux chercher sur le titre, ou sur tout.

Donc, ce qu'on pourrait imaginer, c'est de chercher sur un index donné
(et non pas sur un champ).

A mon sens le plus simple pour ce genre d'interface, c'est de faire la
recherche sur `tout`, puis d'affiner en php à partir des résultats
retournés par `tout`. Au-delà ça revient à définir une application
très particulière, avec donc de la programmation ad hoc.

4) J'ai toujours un problème avec le surlignage après recherche de SPIP.

en effet ça concerne prive/javascript/SearchHighlight.js, c'est une
autre affaire

-- Fil

fil · Mars 14, 2009, 11:06

Bon je l'ai activé sur contrib, mais :
- idée ne donne aucun résultat
- idee donne 77 résultats
- idée donne 143 résultats

c'est strtolower() qui bouffe le é (pourquoi chez toi, et pas chez
moi, je n'en sais rien, mais comme on peut le supprimer...
supprimons).

- Plus grave : la recherche prend beaucoup plus de temps qu'avec la
recherche standard, et le cpu de mon serveur a grimpé en moyenne de 15% à
40%, avec des pointes à 100% à chaque recherche ...

clairement (??) il y avait un problème sur lien2, qu'on résout en faisant :

mysql> ALTER TABLE spip_documents_liens ADD INDEX objet(id_objet,objet);
Query OK, 3560 rows affected (11.31 sec)
Records: 3560 Duplicates: 0 Warnings: 0

Le EXPLAIN devient alors :
+----+-------------+-------+--------+---------------+---------+---------+------------------------------+------+---------------------------------+
| id | select_type | table | type | possible_keys | key |
key_len | ref | rows | Extra
         |
+----+-------------+-------+--------+---------------+---------+---------+------------------------------+------+---------------------------------+
| 1 | SIMPLE | t | index | NULL | PRIMARY | 8
| NULL | 1070 | Using temporary; Using
filesort |
| 1 | SIMPLE | lien1 | ref | PRIMARY | PRIMARY | 8
| spipcont.t.id_rubrique | 2 | Using index
  |
| 1 | SIMPLE | obj1 | eq_ref | PRIMARY | PRIMARY | 8
| spipcont.lien1.id_mot | 1 |
  |
| 1 | SIMPLE | lien2 | ref | objet | objet | 85
| spipcont.t.id_rubrique,const | 3 |
  |
| 1 | SIMPLE | obj2 | eq_ref | PRIMARY | PRIMARY | 8
| spipcont.lien2.id_document | 1 |
  |
+----+-------------+-------+--------+---------------+---------+---------+------------------------------+------+---------------------------------+

et la recherche tourne à la vitesse qu'il faut.

Question : où faut-il ajouter cet INDEX ? Dans le core, ou dans le
plugin ? Et quels autres ?

-- Fil