[spip-dev] spip_index, le retour

Dev
1

Bonjour,
j'ai ameliore la nouvelle version de l'indexation en fonction de vos commentaires (champ id_type au lieu de type)
De plus j'ai poursuivi la demarche en rendant toutes les fonctions d'indexation/recherche generiques
le type de table n'est plus explicite nul part
toutes les configs de champ, poids, objet associes a indexer, criteres d'index se font par des tables globales

Il devient ainsi possible d'ajouter des tables à indexer (contrib, plugin) par simple configuration de ces array, sans toucher au coeur de SPIP
je n'ai pas encore testé cette derniere possibilité, mais ca ne saurait tarder

Enfin, j'ai fait plusieurs essais d'index en repartant depuis des bases 182.
La montee de version estransparente
un raz de l'index suivi d'une reindexation donne des resultats assez comparables a la table spip_index d'origine, sauf pour l'indexation des rubriques.
Dans le cas de mes bases, elles ne comportent qu'un titre et un mot cle qui contient un descriptif assez long
Le volume des mots indexes a double. J'ai regarde l'ordre de grandeur des scores obtenus avec l'occurence des mots concernes et les poids : cela parait assez coherent, meme si eloigne de ce que j'avais avant.
Alors etait-ce un defaut de la 182, ou un bug que je n'ai pas vu ici ?

Toutes vos remarques et vos tests seront les bienvenus pour ameliorer encore tout cela
Le patch etant un petit peut trop gros, je l'ai commite sur la zone, rubrique __dev__, gestion_indexation.
CM

2

excellent, c'est en test sur cahierspip.ww7.be et ca marche du tonnerre.

il faut passer par install.php3 en non par par upgrade.php3 pour
l'upgrade de la base de donnees.

ca sera en stantard dans spip ?

3

j'ai ameliore la nouvelle version de l'indexation en fonction de vos
commentaires (champ id_type au lieu de type)

Sur la base de données d'uzine.net voici ce que ça donne, en terme de
"poids" sur le disque dur (les valeurs sont le nombre de blocks de 1ko
utilisés) :

AVANT

4

Bonsoir,

Fil a écrit :

1) je pense qu'il est dommage d'introduire la table
spip_index_types alors que ça pourrait tout bêtement être un tableau en php.
On a déjà un spip_types_documents dont on veut se débarrasser : pas la peine
de rajouter des tables qui ne contiennent pas de vraies données.

Le jour, plus si lointain, où spip pourra gérer d'autres objets que les cin ou six types actuels, est-ce le concept d'une table spip_types ne deviendra pas justement pertinent ?

François

5

Fil a écrit :

j'ai ameliore la nouvelle version de l'indexation en fonction de vos commentaires (champ id_type au lieu de type)
   
Sur la base de données d'uzine.net voici ce que ça donne, en terme de
"poids" sur le disque dur (les valeurs sont le nombre de blocks de 1ko
utilisés) :

AVANT

blip:/usr/local/mysql/data/spip root# du -skc spip_index_*.MY*
47608 total

APRES

blip:/usr/local/mysql/data/spip root# du -skc spip_index*.MY*
56436 total

La montee de version estransparente
   
Je confirme, à ma grande surprise c'est même assez rapide (une ou deux
minutes à "mouliner" sur mon iBook G4, pour uzine).

Par contre, deux remarques encore :

1) je pense qu'il est dommage d'introduire la table
spip_index_types alors que ça pourrait tout bêtement être un tableau en php.
On a déjà un spip_types_documents dont on veut se débarrasser : pas la peine
de rajouter des tables qui ne contiennent pas de vraies données.

si on s'en tient aux tables de SPIP, un tableau PHP suffirait. Mais l'objectif est de pouvoir generaliser l'indexation a des tables supplementaires introduites par des contribs ou plug-in.
Si l'on utilise un tableau PHP, chaque plug in devrait ajouter son id, mais en fonction de l'ordre de chargement des plug-in, on pourrait avoir des affectations id_type non figees (en particulier : on ajoute un nouveau plugin qui se charge au debut, tous les autres se voient décales d'un dans la table des id)
Par ailleurs, telle quelle, les tables sql ont leur coherence et peuvent être re-exploitées independamment du code, ce qui ne serait plus le cas autrement.
Pour dire vrai, je pensais meme passer en table SQL toutes les infos de config de l'indexation (champs, poids, objets associes ainsi que leurs champs et poids) et faire une beau index_config qui detecte les tables existantes dispo (ou au moins declarees dans tables_principales), met a jour la table d'id, et permet de configurer l'indexation de chaque table (index oui/non, champs a indexer et leur poid, objets associes a indexer)
Cela permettrait de parametrer plus finement le moteur de recherche (quel besoin d'indexer les mots cles sur un site ou ils ne servent qu'a parametrer le squelette par exemple ?) et l'indexation des tables supplementaires sans meme ecrire de code.
Dois-je poursuivre dans cette voie? en stockant les infos en table sql (une table spip_index_config qui eventuellement regrouperait la table spip_index_type que j'ai introduite et les autres infos) ? ou en stockant les infos de config dans un fichier de config (beaucoup moins elegant a mon gout, mais si c'est plus coherent avec la demarche generale pourquoi pas) ?

2) les types sont "article", "auteur", etc. Est-ce que ce ne serait pas plus
générique si on indiquait "spip_articles", "spip_auteurs", de manière à
pouvoir indexer des tables non préfixées par spip_** ?

oui, c'est vrai que j'ai joue petit-bras, là. Je vais ameliorer ça

(A noter : le patch est déjà obsolète par rapport aux mouvements de
fichiers que fait Emmanuel.)

j'ai vu ça. Pas les fichiers sous la main pour recommiter. en gros, le patch du delete_all.php3 doit s'appliquer sur le inc_delete_all.php3.
Je recommiterai Luni, mais surement nouvelle version a venir dans la foulee avec ce que j'ai proposé au dessus.

Dernier point, il faudra vérifier que les INDEX sont posés de manière
pertinente, à coups de EXPLAIN.

??
je vais repotasser mon mySQL illustré. J'ai du m'endormir avant la fin.

6

Fil a écrit :
> 1) je pense qu'il est dommage d'introduire la table
> spip_index_types alors que ça pourrait tout bêtement être un tableau en php.
> On a déjà un spip_types_documents dont on veut se débarrasser : pas la peine
> de rajouter des tables qui ne contiennent pas de vraies données.

Le jour, plus si lointain, où spip pourra gérer d'autres objets que les
cin ou six types actuels, est-ce le concept d'une table spip_types ne
deviendra pas justement pertinent ?

Tu peux dire la même chose de la table spip_types_documents ; mais en
pratique qu'est-ce qu'on constate : qu'une table, c'est pas évident à
manipuler sans interface, bien plus dur qu'un fichier php (pour la plupart
des gens). Et que du coup stocker ces donner "en base" c'est les figer.

D'autre part pour ce qui est du nommage, je ne vois pas vraiment l'intérêt
de numéroter 1,2,3,4,5 ce qui peut être nommé de manière directe (par
exemple pour les articles, brèves, rubriques, sites : a, b, r, s).

Là encore, l'expérience de spip_types_documents devrait être parlante : on a
numéroté là où on aurait dû se baser sur l'extension, et maintenant les
utilsateurs demandent "comment peut-on intégrer les documents OpenOffice2
dans SPIP ?" ; ce serait dans un fichier de config simple, à éditer avec
WordPad, la question ne se poserait pas dans les mêmes termes ; et le besoin
de développer une interface spécifique (ce que personne ne s'est donné la
peine de faire !), serait moindre.

Donc, je maintiens qu'on aurait intérêt à se passer de spip_index_types.

-- Fil

7

Pour dire vrai, je pensais meme passer en table SQL toutes les infos de
config de l'indexation (champs, poids, objets associes ainsi que leurs

.../...

Dois-je poursuivre dans cette voie?

Je dirais, non, et oui. Non, pour tout passer en table d'office, oui pour
continuer dans cette voie. Avec une démarche KISS (keep it simple stupid).

Dans le core, des choses simples, le moins de tables et de "bells and
whistles" possibles. En sachant que rien n'interdit d'ajouter par ailleurs
des interfaces de configuration top-moumoute pour les power-users. Mais ces
interfaces-là ont vocation à être des plugins ; le core se doit d'être le
plus simple possible, pour être robuste, maintenable, compréhensible, etc.

L'unification des spip_index_** est un excellent pas vers la simplification.
L'ajout d'interfaces de commande de Boeing par-dessus, doit plutôt être vu
comme un plugin/contrib externe.

Je précise que c'est une règle à adopter aussi pour les trucs produits par
"spip core" : j'ai récemment sorti du core le "client podcast", que je
jugeais trop lourd, pour le passer en plugin. La syndication par défaut
fonctionne grosso modo pour tout le monde, mais certain (BoOz pour ne pas le
nommer) ont besoin de choses plus complètes.

>Dernier point, il faudra vérifier que les INDEX sont posés de manière
>pertinente, à coups de EXPLAIN.
??
je vais repotasser mon mySQL illustré. J'ai du m'endormir avant la fin.

Il faut vérifier que les requêtes s'exécutent aussi vite qu'avant (ou aussi
lentement, c'est selon :slight_smile: et exploitent bien l'index qu'on a fixé (sinon,
changer l'index).

-- Fil

8

Fil a écrit :

Fil a écrit :
   

1) je pense qu'il est dommage d'introduire la table
spip_index_types alors que ça pourrait tout bêtement être un tableau en php.
On a déjà un spip_types_documents dont on veut se débarrasser : pas la peine
de rajouter des tables qui ne contiennent pas de vraies données.
     

Le jour, plus si lointain, où spip pourra gérer d'autres objets que les cin ou six types actuels, est-ce le concept d'une table spip_types ne deviendra pas justement pertinent ?
   
Tu peux dire la même chose de la table spip_types_documents ; mais en
pratique qu'est-ce qu'on constate : qu'une table, c'est pas évident à
manipuler sans interface, bien plus dur qu'un fichier php (pour la plupart
des gens). Et que du coup stocker ces donner "en base" c'est les figer.

...
Donc, je maintiens qu'on aurait intérêt à se passer de spip_index_types.

pour spip_index_types, je continue a penser qu'elle est indissociable de spip_index. Sans cette table spip_index n'a pas de signification. Donc cela veut dire que la base ne forme plus une unite atomique qui se suffit a elle meme. Cela me semble assez discutable comme choix.
Pour l'aspect config, je comprend tes reticences. Une bonne solution serait de faire en sorte que cette table soit mise a jour automatiquement en fonction des tables declarees dans tables_principales. Ainsi, il n'est plus necessaire de l'editer ni de la modifier. Sa gestion devient transparente pour l'utilisateur moyen.
Est-ce un compromis acceptable ?

9

Fil a écrit :

Pour dire vrai, je pensais meme passer en table SQL toutes les infos de config de l'indexation (champs, poids, objets associes ainsi que leurs
   

.../...

Dois-je poursuivre dans cette voie?
   
Je dirais, non, et oui. Non, pour tout passer en table d'office, oui pour
continuer dans cette voie. Avec une démarche KISS (keep it simple stupid).

...
L'unification des spip_index_** est un excellent pas vers la simplification.
L'ajout d'interfaces de commande de Boeing par-dessus, doit plutôt être vu
comme un plugin/contrib externe.

...

Je vois l'esprit. Je reserve cette interface de config en plug-in (du coup ca lui enleve un peu d'urgence)
Entre-temps, j'ai testé l'ajout de tables d'indexations. Tout marche comme prevu par config des tables PHP INDEX_xx.
La seule operation 'delicate' reste l'insertion dans spip_index_type. cf mon autre mail ou je propose donc une mise a jour auto de cette table pour eviter toute intervention manuelle sur mysql.

CM

10

pour spip_index_types, je continue a penser qu'elle est indissociable de
spip_index. Sans cette table spip_index n'a pas de signification.

Il ne faut rien exagérer :slight_smile:

Cela dit tu as raison, c'est pas mal si les données forment un tout
"intègre". D'un autre côté, ce ne sont pas vraiment des données, au sens où
l'utilisateur les aurait entrées. Si on les perd, on sait les recréer. Ce
qui amoindrit l'exigence d'auto-cohérence de la base.

Une suggestion : si tu veux mettre les descriptions dans la base, tu peux
aussi utiliser spip_meta, qui te permet de stocker des petites données de
configuration facilement.

Est-ce un compromis acceptable ?

Question d méthode : l'idée n'est pas de chercher un "compromis", sorte de
milieu entre deux positions, mais de se convaincre, pour s'acheminer vers un
consensus ; donc tant qu'on n'est pas convaincus d'avoir "la" bonne
solution, il faut discuter. Oui, c'est long et lent, mais c'est aussi comme
ça qu'on arrive à faire avancer les choses.

Pour revenir à cette table complémentaire, je ne la "sens" pas, car elle
ressemble trop à spip_types_documents, qui nous plombe (un peu, mais depuis
longtemps). Je n'ai toutefois pas d'argument massue pour dire qu'il faut
s'en débarrasser, c'est plutôt une intuition...

-- Fil

11

Fil a écrit :

pour spip_index_types, je continue a penser qu'elle est indissociable de spip_index. Sans cette table spip_index n'a pas de signification.
   
Il ne faut rien exagérer :slight_smile:

Cela dit tu as raison, c'est pas mal si les données forment un tout
"intègre". D'un autre côté, ce ne sont pas vraiment des données, au sens où
l'utilisateur les aurait entrées. Si on les perd, on sait les recréer. Ce
qui amoindrit l'exigence d'auto-cohérence de la base.

Une suggestion : si tu veux mettre les descriptions dans la base, tu peux
aussi utiliser spip_meta, qui te permet de stocker des petites données de
configuration facilement.

Je ne comprend pas pourquoi un ENUM ne fait pas l'affaire ... j'ai peut etre raté un episode..

C'est aussi petit qu'un id, ca tient dans une seule table, et la donnée est consistante.
Ca n'est pas bien dur de faire un alter table pour ajouter une possibilité (et ajouter une table à indexer, on ne le fait pas tous les jours)
De toutes facons, à terme, cela doit pouvoir s'automatiser (lire les valeurs possibles et l'ajouter si elle n'existe pas) en fonction d'une simple declaration (vu qu'on peut declarer la structure, autant s'appuyer sur cette declaration pour dire si la table est à indexer ou non), toujours dans l'idée d'un mise à jour de la config automatisée, mais déclenchée par l'admin depuis l'interface de configuration.

Mes 2 sous.

@++

PS : pas de reseau pendant 1 semaine pour moi, alors je vous souhaite une bonne recherche de consensus ...
et joyeux noel !