[SPIP Zone] Fulltext avec la pondération d'origine

[fil]

Il me semble que la méthode de dire "on prend ce qu'on veut comme
FULLTEXT" inclut la méthode que tu proposes. Si tu regardes comment
les index sont pondérés, c'est fait avec le nombre de champs qu'ils
contiennent. Bien sûr, on peut introduire une méthode un peu
différente, qui pondérerait en fonction du poids total des champs
qu'ils contiennent (c'est peut-être ce que tu as fait, je n'ai pas
réussi à lire ton fichier joint).

On gagne tellement avec ce plugin, qu'on peut se fiche de la perte de
compatibilité avec un truc qui ne marchait pas et assumer, en cas de
besoin, un changement.

En revanche, aucune idée de l'impact sur les perfs et l'occupation
disque, il faudra tester. On fait une requête MATCH AGAINST par index,
mais sur les petits champs (titre) ça répond plus vite que sur les
index composés comprenant des gros champs (texte).

Enfin il me semble que si on veut que "+A +B" réponde lorsque le titre
contient A et le texte B, il *faut* un index sur (titre, texte).

PS : je repasse sur la liste car il y a déjà au moins 4 devs sur ce plugin.

2009/3/16 Martin Arnaud <arno@rezo.net>:

Salut Fil,

J'ai fait des modifs pour, me semble-t-il, récupérer directement les valeurs
de pondération de SPIP, qui sont par ailleurs super-faciles à enrichir par
plugin (une fois qu'on a trouvé le bon pipeline non documenté :-)).

Parce que le coup des index multiples pour parvenir à fabriquer une
pondération, je trouve ça franchement pas pratique, et en plus ça introduit
une perte de compatibilité.

J'ai donc modifié rechercher.php pour réintroduire les pondérations dans le
fulltext. Je crois qu'il faut, du coup, avoir un index fulltext par champ.
Et pas des index avec plusieurs champs d'un coup.

Qu'est-ce que tu en penses? Est-ce que ça risque, en revanche, d'introduire
des lourdeurs dans les performances?

Arnaud

[fil]

FULLTEXT" inclut la méthode que tu proposes. Si tu regardes comment

je voulais dire "inclue" (?).

différente, qui pondérerait en fonction du poids total des champs
qu'ils contiennent

je voulais dire du "poids moyen" ; mais à la réflexion on peut faire
un peu plus d'arithmétique pour tenir compte du fait que la
surpondération du titre est déjà prise en compte par l'index titre,
etc.

-- Fil

[fil]

je voulais dire "inclue" (?).

en fait non

-- Fil

[arno]

Bon, je m'ai planté et j'ai répondu en privé.

Voici mon message précédent, la réponse de Fil, et une précision:

Ce qui me semblerait intéressant:

- j'installe le plugin,

- je lance une recherche, là le truc découvre que j'ai des pondérations déclarées (c'est déjà plus ou moins le cas);
- dans le même temps, je vérifie la présence FULLTEXT sur ces champs (c'est déjà le cas, justement);

- SI je n'ai pas la présence FULLTEXT, ça l'ajoute illico, champ par champ; c'est tout con;

- et voilà, mon plugin m'a fait passer en recherche fulltext en conservant la pondération de SPIP, mes développements et mes plugins précédents.

L'idée:
- je n'ai pas à lancer un EXEC pour faire des modifs de la base;
- si j'ai un plugin qui m'a ajouté un champ dans, disons, spip_articles, hé ben hop c'est fulltext, avec la pondération qui va bien, et sans que ce soit bien compliqué de déclarer dans mySQL les index surnuméraires (si j'active ce plugin après le passage de spip_articles en FULLTEXT, je n'ai pas plus de difficulté).

A*

Le 16 mars 09 à 14:21, Fil a écrit :

- conserver la simplicité de la déclaration de la pondération; dans mon cas,
trois tables, avec des déclarations de pondération trop fastoches:
$vars['auteurs_metier'] = array('nom'=>8, 'prenom'=>5, 'bio'=>2, 'email'=>5);
$vars['etablissement'] = array('type'=>3,
'nom'=>5,
'adresse1'=>1,
'adresse2'=>1,
'code_postal'=>10,
'ville'=>5,
'pays'=>5
);

...

exact, mais tu pourrais avoir la même chose en indiquant le nom des
index au lieu de celui des champs ! et dans ton cas en effet, avec un
index par champ, tu retrouverais tes petits

- conserver la précision des réglages. Et de ce côté, il y a un aspect
débile pourtant important pour moi: mes interlocuteurs _veulent_ une
pondération super-précise, parce que ça leur donne l'impression qu'ils sont
intelligents quand ils me demandent de pondérer le nom à 8 au lieu de 7,
même si ça ne donnera rien de flagrant dans les recherches... Quand tu
présentes ton machin en entretien pendant un appel d'offre, y'a un des
interlocuteurs qui a les yeux qui s'éclairent quand tu lui parles des liens
insécables insérés _automatiquement_ avant les points-virgules et les
apostrophes typographiques, et y'en a un autre qui veut t'épouser quand tu
évoques la finesse de la pondération du moteur de recherche :-))

tu estimes qu'il faut modifier mon plugin pour mieux vendre devant les clients ?
il est où mon pourcentage là ?

- ma modif réintroduit le système de pondération déclarée en PHP de manière
transparente (on conserve la déclaration en PHP).

Les modifs:

tu peux me l'envoyer zippé que je regarde en détail ?

- dans function fulltext_keys, j'explose les clés pour récupérer champ par
champ; en fait, c'est pas une bonne idée, parce qu'un index multiple n'est
finalement pas utilisable champ par champ;

hé non

C'est le calcul de $mult qui change, puisqu'on lui applique la valeur de
podération, au lieu de la valeur calculée selon le nombre de champs.

absolument c'est là qu'il faut agir

Je crois qu'il serait plus facile de faire l'insertion des index FULLTEXT
dans mySQL (et de les manipuler en temps réel) comme ça qu'en modifiant «en
dur» leur nombre dans la base de données.

on le faire en mou (si tu me passes l'expression) avec la page
exec=fulltext ; il suffit de l'améliorer

-- Fil

[fil]

- SI je n'ai pas la présence FULLTEXT, ça l'ajoute illico, champ par champ;
c'est tout con;

Non c'est pas tout con : il faut déjà être en MyISAM, vérifier qu'on
est bien encodé en utf8 etc.

Par ailleurs sur mes tests actuels (rezo et le diplo) j'ai de bien
meilleurs résultats (qualitativement parlant) avec un index pour le
champ titre et un index pour l'ensemble des autres champs. Avec ta
proposition je ne pourrai plus faire ça puisque le plugin s'ingéniera
à me créer un index par champ.

Par contre je viens d'intégrer une partie de ta propale : si un index
porte sur un champ (unique) et connu de $liste[$table], ça fixe son
$mult à cette valeur : [27356].

L'idée:
- je n'ai pas à lancer un EXEC pour faire des modifs de la base;

Fausse bonne idée, pour au moins deux raisons :
- je veux pouvoir faire autrement
- c'est pas si simple il faut vérifier le charset et d'autres trucs

Par contre il est clair qu'il faut un lien vers ce exec=fulltext dans
la page admin-plugins

- si j'ai un plugin qui m'a ajouté un champ dans, disons, spip_articles, hé
ben hop c'est fulltext, avec la pondération qui va bien, et sans que ce soit
bien compliqué de déclarer dans mySQL les index surnuméraires (si j'active
ce plugin après le passage de spip_articles en FULLTEXT, je n'ai pas plus de
difficulté).

le exec=fulltext, s'il avait une interface bien pensée, permettrait de faire ça

-- Fil

[19eb0d0ad6f2ebee089f]

2009/3/16 Martin Arnaud <arno@rezo.net>:

Salut Fil,

J'ai fait des modifs pour, me semble-t-il, récupérer directement les valeurs
de pondération de SPIP, qui sont par ailleurs super-faciles à enrichir par
plugin (une fois qu'on a trouvé le bon pipeline non documenté :-)).

Meuh si, quelques-uns le sont
http://programmer.spip.org/rechercher_liste_des_champs

--
MM.

[fil]

http://programmer.spip.org/rechercher_liste_des_champs

Avec unset($tables['rubrique']['descriptif']); mon histoire ne marche
pas. Peux-tu mettre unset($tables['rubrique']['descriptif']) = 0 ?

-- Fil