[spip-dev] Documentation de l'API (provisoire et discutable) inc/rechercher

{{{L'API inc/rechercher}}}

Avec cette API SPIP dispose de trois fonctions :

-- <code>liste_des_tables()</code> indique la liste standard des
tables et des champs dans lesquels on peut faire une recherche
textuelle.

-- <code>recherche_en_base($recherche)</code> retourne la liste des
objets dont l'un des champs "matche" la recherche (au sens de
preg_match).

Cette liste est sous la forme d'un tableau de tableaux, listant, pour
chaque type d'objets, les objets concernés (avec leur id et les champs
concernés, ceux qui ont un "match").

<code>
recherche_en_base('toto') =>

array (
  'article' => array (
    123 => array (
      id_article => 123,
      texte => 'toto...'
    ),
    125 => etc,
  'rubrique' => array (
    12 => array (
      id_rubrique => 12
      descriptif => 'Rubrique toto'
    )
  )
)
</code>

On peut passer comme deuxième paramètre un array correspondant à
<code>liste_des_tables()</code> : soit pour faire une recherche dans
un champ non standard, soit pour ajouter un type de table, soit pour
retirer un type de table.

Par exemple pour chercher partout sauf dans les documents et forums :
<code>
$tables = liste_des_tables();
unset($tables['document']);
unset($tables['forum']);
recherche_en_base('toto', $tables);
</code>

Le troisième paramètre est un tableau d'options.
- toutvoir pour eviter autoriser(voir)
- flags pour eviter les flags regexp par defaut (UimsS)

Exemple :
<code>
recherche_en_base('A.*B', NULL, array('toutvoir'=>true, 'flags'=>'UmsS');
</code>

-- <code>remplace_en_base($recherche, $remplace)</code> permet de
faire un preg_replace() général sur l'ensemble de la base. Il utilise
recherche_en_base puis, pour chaque objet « matché », effectue le
preg_replace() correspondant, et réinjecte le tout dans la base de
données en utilisant l'API <code>inc/modifier</code>.

Exemple : chercher "toto" et remplacer par "tata" :

<code>
var_dump(recherche_en_base('toto'));
remplace_en_base('toto', 'tata');
var_dump(recherche_en_base('tata'));
</code>

Son troisième est la liste des tables et champs concernés.

Son quatrième paramètre correspond aux options de recherche_en_base(),
avec, en plus, l'option 'toutmodifier' pour éviter
autoriser(modifier).

{{Attention}} ces fonctions peuvent être relativement lentes.

{{{L'API inc/rechercher}}}

Avec cette API SPIP dispose de trois fonctions :
[...]

Ouah !!!

Si je ne m'abuse, ça permettrait notamment de rechercher <doc12(|.*)? > dans tous les contenus pour savoir si le doc 12 attaché à l'article que je veux supprimer est utilisé ailleurs ?

Et donc, mon plugin liens_contenus perd de la valeur, ce qui me fait très plaisir puisque cela signifie que mon besoin est de plus en plus intégré au core... :wink:

-Nicolas

Si je ne m'abuse, ça permettrait notamment de rechercher <doc12(|.*)?
> dans tous les contenus pour savoir si le doc 12 attaché à
l'article que je veux supprimer est utilisé ailleurs ?

Euh, sans doute. Evite le |.* tout de même :slight_smile:

-- Fil

Si je ne m'abuse, ça permettrait notamment de rechercher <doc12(|.*)?
> dans tous les contenus pour savoir si le doc 12 attaché à
l'article que je veux supprimer est utilisé ailleurs ?

Euh, sans doute. Evite le |.* tout de même :slight_smile:

Oui, ce sera plutôt un <doc12(|[^>]*)?> ... :wink:

-Nicolas

Oui, ce sera plutôt un <doc12(|[^>]*)?> ... :wink:

Je m'attendais à plus de commentaires (d'un autre côté on n'est pas
pressés), voire des propositions de patches. J'hésite en fait à
publier cette API car il me semble qu'elle est incomplète. On devrait
pouvoir passer a minima quelques critères WHERE pour restreindre la
recherche. (Par exemple ne chercher que sur les articles WHERE
statut='publie').

-- Fil

Oui, ce sera plutôt un <doc12(|[^>]*)?> ... :wink:

Je m'attendais à plus de commentaires (d'un autre côté on n'est pas
pressés), voire des propositions de patches. J'hésite en fait à
publier cette API car il me semble qu'elle est incomplète. On devrait
pouvoir passer a minima quelques critères WHERE pour restreindre la
recherche. (Par exemple ne chercher que sur les articles WHERE
statut='publie').

Effectivement, ce serait intéressant, voir nécessaire si on l'utilise dans des plugins qui génèrent du contenu public.

Ce serait aussi super de pouvoir obtenir dans le résultat le nombre d'occurrences du terme, pour construire sa propre gestion de pertinence plus simplement.

-Nicolas

Fil wrote:

Je m'attendais à plus de commentaires (d'un autre côté on n'est pas
pressés), voire des propositions de patches.

Comme tu sais je ne suis pas très qualifié pour discuter du code...

Si la base de données passera (un jour !) en texte UTF-8, il serait possible de faire des recherches MySQL plus simples ? Ou est-ce que je me trompe ?

Paolo

I have to ask a stupid question :slight_smile:

The API is intended to work for all kind of searches, from public and private spaces?

Renato

Nicolas Hoizey wrote:

Oui, ce sera plutôt un <doc12(|[^>]*)?> ... :wink:

Et même

<doc12(\|[^>]*)?>

Ce serait aussi super de pouvoir obtenir dans le résultat le nombre
d'occurrences du terme, pour construire sa propre gestion de
pertinence plus simplement.

C'est vrai qu'on refait un preg_match, ça ne doit pas coûter beaucoup
plus cher de faire un preg_match_all(). (Essaie ?)

-- Fil

Au départ j'ai eu envie de coder ça parce que je devais faire un
chercher/remplacer global sur la base de données, et j'ai perdu du
temps à essayer de "le faire vite". Je n'ai pas d'idée des
applications possibles ; d'ailleurs quand tu codes une API en général
les gens l'utilisent pour autre chose que ce que tu avais imaginé
(exemple Nicolas avec la recherche des <doc12>).

-- Fil

The API is intended to work for all kind of searches, from public and
private spaces?

Maintenant que tu le dis, ça pourrait permettre d'éliminer presque
tout le code d'indexation/recherche du core, pour le passer en plugin
; par défaut {recherche} appellerait directement la base de données.
Le plugin permettrait d'assurer l'indexation telle qu'elle existe
déjà, pour être sûrs au minimum de ne pas perdre en performances sur
de "gros" sites. Ca permettrait sans doute de relancer le
développement du moteur de recherche.

-- Fil

Fil ha scritto:

The API is intended to work for all kind of searches, from public and
private spaces?

Maintenant que tu le dis, ça pourrait permettre d'éliminer presque
tout le code d'indexation/recherche du core, pour le passer en plugin
; par défaut {recherche} appellerait directement la base de données.
Le plugin permettrait d'assurer l'indexation telle qu'elle existe
déjà, pour être sûrs au minimum de ne pas perdre en performances sur
de "gros" sites. Ca permettrait sans doute de relancer le
développement du moteur de recherche.

-- Fil

I have just viewed the code and now I start to understand.
Well, I imagined the API was intended to get advantage from the index of SPIP but now I realize it is not the case, it is a full text search.

Maybe the API could be extended to do full text searches and indexed searches.

I don't know if moving the indexed search out of the core could be a good move, but, maybe this can be done if we think to provide SPIP core with a set of default plugins already activated, among which there should be the recherche plugin. In this way, the users won't be bothered to download and install the plugins implementing such features that, for those that are used to have them, can be quite confusing. On the other side, those "official" plugins, could be disabled during the install procedure, if the webmaster thinks he will not use them, saving some processing time and db space.

Renato

Maybe the API could be extended to do full text searches and indexed
searches.

Oui, dans le plugin "recherche" :slight_smile:

I don't know if moving the indexed search out of the core could be a
good move, but, maybe this can be done if we think to provide SPIP core
with a set of default plugins already activated, among which there
should be the recherche plugin.

Je pense que la bonne solution serait de faire une page exec=plugins
qui permette de télécharger et installer d'un seul clic (à la
spip-loader) un certain nombre de plugins "officiels", avec des liens
vers plusieurs collections de plugins.

-- Fil

avec des liens
vers plusieurs collections de plugins.

-- Fil

Ce qui demande d'affiner la catégorisation des plugins... c'est peut-être l'occasion de s'y mettre.

RB

* Fil tapotait, le 04/05/2007 23:22:

The API is intended to work for all kind of searches, from public and
private spaces?

Maintenant que tu le dis, ça pourrait permettre d'éliminer presque
tout le code d'indexation/recherche du core, pour le passer en plugin
; par défaut {recherche} appellerait directement la base de données.
Le plugin permettrait d'assurer l'indexation telle qu'elle existe
déjà, pour être sûrs au minimum de ne pas perdre en performances sur
de "gros" sites. Ca permettrait sans doute de relancer le
développement du moteur de recherche.

Au passage, une idée que l'on m'a soumise il y a quelques temps : pouvoir mémoriser les recherches infructueuses afin de savoir quel contenu les visiteurs s'attendait à pouvoir trouver sur le site.

RealET wrote:

Au passage, une idée que l'on m'a soumise il y a quelques temps :
pouvoir mémoriser les recherches infructueuses afin de savoir quel
contenu les visiteurs s'attendait à pouvoir trouver sur le site.

ne risques-tu pas de stocker inutilement des fausses requêtes émanant de
bots ? Faut voir si le rapport "signal/bruit" vaut le coût ou pas...

Nicolas

Au passage, une idée que l'on m'a soumise il y a quelques temps :
pouvoir mémoriser les recherches infructueuses afin de savoir quel
contenu les visiteurs s'attendait à pouvoir trouver sur le site.

C'est une idée intéressante, effectivement !

ne risques-tu pas de stocker inutilement des fausses requêtes émanant de
bots ? Faut voir si le rapport "signal/bruit" vaut le coût ou pas...

C'est un risque, mais on doit pouvoir ne conserver que les recherches vraiment faites depuis le site, selon le REFERER, ce qui limite déjà pas mal.

-Nicolas

* Nicolas Hoizey tapotait, le 07/05/2007 21:00:

Au passage, une idée que l'on m'a soumise il y a quelques temps :
pouvoir mémoriser les recherches infructueuses afin de savoir quel
contenu les visiteurs s'attendait à pouvoir trouver sur le site.

C'est une idée intéressante, effectivement !

ne risques-tu pas de stocker inutilement des fausses requêtes émanant de
bots ? Faut voir si le rapport "signal/bruit" vaut le coût ou pas...

C'est un risque, mais on doit pouvoir ne conserver que les recherches vraiment faites depuis le site, selon le REFERER, ce qui limite déjà pas mal.

Effectivement.

Ceci dit, l'ensemble de ces recherches sont *déjà* dans les log d'apache.

Donc, pour gérer les stats de SPIP, ne vaudrait-il pas mieux faire un SPIPalyser ?

RealET wrote:

Ceci dit, l'ensemble de ces recherches sont *déjà* dans les log d'apache.

certes, mais en mutualisé, tu n'y a pas forcément accès (ou pas depuis le
web)

Donc, pour gérer les stats de SPIP, ne vaudrait-il pas mieux faire un
SPIPalyser ?

Pourquoi un awstats / webalyser / ... ne suffirait pas dans ce cas là ?

Nicolas