SPIP ecureuil




Thème de ce forum :

>Fonction recherche incompatible avec mySQL 4.1.8



Gérard
>Fonction recherche incompatible avec mySQL 4.1.8
20 janvier 2005 17:16

Après installation d’un nouveau site il est apparu que la fonction recherche fonctionnait mal, certains mots n’étaient pas trouvés, même après ré-indexation manuelle du site.

Finalement je me suis résolu à mettre les mains dans le cambouis et j’ai découvert que l’indexation fonctionnait parfaitement (les mots étaient bien présents dans la table `shim_spipnet`.spip_index_dico) mais que la recherche se plantait aléatoirement dans recherche.php3 :

... requete_txt_integral(’article’, $hash_recherche) ; qui formate la requête SQL : ... AND rec.hash IN ($hash_recherche) et ça il ne trouve pas dans la table et pourtant il existe !

Tout paraissait correct et je suis resté perplexe jusqu’au moment où j’ai eu le flash : les mots non trouvés avaient tous des hash négatifs (du moins qui seraient négatifs en BIGINT).

J’ai alors pu reproduire facilement le problème, ce n’est pas un bug de SPIP mais un bug de mySQL version 1.4.8. J’ai émis un rapport d’anomalie chez eux (bug no 8009).

Donc vous avez intérêt à ne pas migrer trop vite sur la dernière version de mySQL, statistiquement vous ne trouverez que la moitié des mots que vous cherchez !

Rechercher dans les forums:
 

PROXYMA CS
20 janvier 2005 19:42
> >Fonction recherche incompatible avec mySQL 4.1.8

Salut et bravo !!!

Oui, bravo pour avoir trouvé un truc pareil. C’est quand même super super chaud à analyser et à trouver la cause de ce type de problème.

Je vous salue bien bas Monsieur pour votre analyse et vos conclusions ...

A+

Gérard
21 janvier 2005 10:22
> >Fonction recherche incompatible avec mySQL 4.1.8

Merci, ça fait plaisir ! et ça m’encourage pour en trouver d’autres

24 janvier 2005 16:10
> >Fonction recherche incompatible avec mySQL 4.1.8

Il semblerait que plus rien ne marche avec la fonction recherche.

Pfff, ke passa ?

Any idea ?

Merci !

7 février 2005 18:39
> >Fonction recherche incompatible avec mySQL 4.1.8

Alors là, franchement bravo pour avoir trouvé ce bug !

J’ai exactement ce problème avec le moteur de recherche.

- SPIP 1.7.2
- MySQL 4.1.9
- Linux Debian Sarge

En attendant que MySQL corrige ce bug, je vais re-installer une version antérieure.

Mille mercis d’avoir trouver l’origine de ce problème !

30 mai 2005 12:40
> Fonction recherche incompatible avec mySQL 4.1.8

Dans ecrire/inc_index.php3 j’ai remplacé ligne 473

$h[] = "0x".$row2["hx"] ;

par

$h[] = "CAST(0x".$row2["hx"]." AS UNSIGNED)" ;

pour être certain que la valeur soit traitée comme un nombre.

6 septembre 2005 13:12
Free + mySQL 4.1.13 = recherche dans le potage

Les serveurs de Free viennent de passer en mySQL 4.1.13 et visiblement le problème n’est pas réglé. Avant c’était parfait mais là, c’est à pleurer : sur un site consacré à Joe Hill, la recherche "Joe Hill" donne... aucun résultat. Et pourquoi, mais pourquoi la recherche dans la partie privée, elle, donne des réponses (pas toutes mais quelques unes, une dizaine en l’occurence - mais c’est pas lourd) ?!

La soluce proposée ici ne marche apparemment pas. Je précise que je suis aussi en 1.8.1.

Est-ce seulement mySQL ? ou les serveurs ? ou SPIP ? ou Georges Bush (on sait jamais) ?

Fil
6 septembre 2005 15:37
>Fonction recherche incompatible avec mySQL 4.1.8

C’est forcément la faute de George Bush. Cela dit si tu essaies SPIP 1.8.2 le problème est censé être réglé (il faut aussi relancer l’indexation).

7 septembre 2005 10:49
>Fonction recherche incompatible avec mySQL 4.1.8

Effectivement, avec la 1.8.2d le texan est terrassé, ouf, de ce côté tout est rentré dans l’ordre...
Mais il est revenu par la fenêtre (le texan est coriace) : l’euprade vers 1.8.2d s’est mal passé !

magellan
15 septembre 2005 12:31
>Fonction recherche incompatible avec mySQL 4.1.8

Dans ecrire/inc_index.php3 j’ai remplacé ligne 473

$h[] = "0x".$row2["hx"] ;

par

$h[] = "CAST(0x".$row2["hx"]." AS UNSIGNED)" ;

pour être certain que la valeur soit traitée comme un nombre.

Bonjour,

L’as-tu fait uniquement pour $h[] ou l’as-tu fait aussi pour $h_strict[] ?

heddy
25 octobre 2005 12:41
>Fonction recherche incompatible avec mySQL 4.1.8 et meme 4.1.14

Bon restons calme...

- SPIP 1.8.1 (avec le hack sur ecrire/inc_index.php3 , ligne 473 cité plus haut),
- mysql 4.1.14

Vidé tous les caches possibles, tout réindexé avec wget ... désactivé le moteur, puis réactivé, modifié mes articles pour rien, encore re-réindexé ... etc etc etc

et, et, et ... toujour rien dans le moteur de recherches !!!!!!!!!!!!! aucun résultat, nothing, nada, clum, que dalle, rien de rien, moins que pas bezef, - l’infini, ...

Il me faut une solution rapide svp !!! help !! o sec !! sos !! ---...--- !!

Loïc
3 novembre 2005 15:56
>Fonction recherche incompatible avec mySQL 4.1.8

J’ai le même problème : Free+SPIP 1.8.1 Que faire ? Y-a-t-il une bidouille magique, genre rendre positif le hash-code des mots ? Est-ce-que SPIP 1.8.2 marche mieux ?

heddy
4 novembre 2005 12:18
>Fonction recherche incompatible avec mySQL 4.1.8

J’ai finalement réussi a faire fonctionner ce ¹#&@*% de moteur de recherches, j’ai tout mis à jour spip, apache, php, mysql ... vidé la base, reindexé (pas oublier d’aller sur ecrire/admin_index.php et de modifier la valeur dans reindexer...) et maintenant ça fonctionne... je sais pas quelle étape à résolu le pb mais ça m’a bien pris la tête ce truc à la fin.

Bon courage

un spipeur qui en a raz le bol
28 février 2006 16:27
>Fonction recherche incompatible avec mySQL 4.1.8

Bonjour tous le monde,

Ben moi aussi j’ai le problème avec mon spip 1.8.1 et MySQL 4.1.12

le hic c’est que si je vais la modification proposée !!! ligne 473 du fichier /ecrire/inc_index.php3

Et bien je n’ai plus aucun résultats qui s’affichent !!! alors entre la moitié qui ne fonctionne pas ou plus rien !!!

QQun pourait-il donné la manip a faire pour que cela fonctionne.

P.S je précise que j’ai bien vidée le cache de spip !!! que j’ai détruit les indexs !!! forcer la reconstruction des index via /ecrire/admin_index.php3 mais rien n’y fait ce foutu moteur ne m’affiche aucun résultat

Arnaud Aebischer
3 mars 2006 16:08
>La solution !!!!

Bonjour à tous,

En fait il ne suffit pas de corriger la ligne 473 dans le code...

Il faut en corrigé un petit peu plus que cela pour que le moteur fonctionne avec SPIP 1.8.1 et MySQL 4.1.X

remplacer dans le fichier ecrire/inc_index.php au lignes 461 à 473

par :

« Ce bout de code a été repris du fichier : ecrire/inc_index.php de SPIP 1.8.2 »

Ensuite il faut détruire les indexs via l’espace admin en utilisant la page admin_index.php3 (il faut taper le nom de la page car aucun lien dans l’espace admin n’est présent pour atteindre cette page !) et les reconstruie en utilisant le 2ème lien dans cette page jusqu’a avoir toutes les diodes vertes qui sont remplies complétement !!!

 :-))

Meilleurs message

Véro
1er avril 2006 17:46
>Fonction recherche incompatible avec mySQL 4.1.8

Bonjour,

Je viens de me pencher sur ce problème, signalé depuis notre migration par des utilisateurs. Merci pour cette réponse que je viens de tester, et qui fonctionne parfaitement bien ! Merci pour tous vos efforts (j’ai lu l’ensemble des messages) et bravo a la communauté.

Nico
15 novembre 2006 14:44
>Fonction recherche incompatible avec mySQL 4.1.8

Bonjour,

nous sommes sur SPIP 1.9.1 avec mySQL 4.1.12

la recherche ne fonctionne pas correctement, les résultats obtenus dans l’administration ne correspondent pas à ceux obtenus dans le site, si je fais une recherche sur le mot "livre" ou "Livre" j’obtiens 1 résultat, alors que ce mot est présent dans plusieurs articles, si je fais une recherche sur "livre foncier" j’obtiens beaucoup plus de résultat alors que c’est écrit "Livre foncier" dans les articles.

enfin c’est un peu n’importe quoi.

le bout de code cité dans ce thread a bien été ajouté dans la version 1.9.1.

Est-ce que d’autres personnes ont été confrontées à ce problème avec la version 1.9.1 et mySQL 4.1x ?

d’avance merci pour vos suggestions.

Nicolas

Jacques Roux
24 novembre 2006 13:12
>Fonction recherche incompatible avec mySQL 4.1.8

Je confirme la rémanence du problème d’indexation avec SPIP 1.9 : sur un site perso hébergé par 1and1 et aussi sur une machine sous mandriva 2006 avec mySQL 4.12. Certains mots trouvés pas d’autres. Je pensais promouvoir SPIP pour un site d’une Société (dite) savante (terme consacré) pour permettre la création d’une base ouverte de documents. La fonction d’indexation est critique pour ce type d’utilisation. Je suis donc un peu perplexe, à la fois laudatif pour la qualité et l’agrément d’emplois et un peu au désespoir de ne pouvoir utiliser ce logiciel pour un site communautaire national. L’indexation est vraiment critique. Bien que vieux programmeur je n’ai vraiment pas les bases techniques pour espérer résoudre ce problème, dont la persistence au travers des versions indique la difficulté ? Y a-t-il un espoir de solution en vue ?

Géraud
1er janvier 2007 15:02
>Fonction recherche incompatible avec mySQL 4.1.8

Bonjour,

juste un petit mot pour vous dire que le problème décrit ici est reproduit sur spip 1.8.2.g, tournant sur mysql 5.0.18.

Je ne crois pas que le bug soit lié à mysql...

merci aux développeurs de spip ! Géraud

Patrice Lazareff
25 mai 2007 11:28
>Fonction recherche incompatible avec mySQL 4.1.8

Bonjour,

SPIP 1.9.1
MySQL 4.0.25 (Mutualisé OVH)

Après avoir forcé la réindexation depuis l’admin, aucun résultat ne sortait du moteur de recherche public.

J’ai trouvé le correctif consistant à effacer l’entrée INDEX_elements_objet de la table spip_meta et c’est reparti.

Mais là une recherche "abcd" ne donne rien alors que "ABCD" fonctionne parfaitement.

Pour contourner le problème, j’ai ajouté en tête de spip.php

if(isset($GLOBALS["recherche"])){
        $GLOBALS["recherche"] = strtoupper($GLOBALS["recherche"]);
}

et tout semble fonctionner parfaitement... en espérant que ça peut aider à trouver l’origine du problème...

25 novembre 2007 16:05
>Fonction recherche incompatible avec mySQL 4.1.8

Je suis en SPIP 1.9.2c [10268] et tourne sur un serveur MySql 5.0.45 chez free.fr. J’utilise les squelettes Alternative Revision : 15284.

Ma fonction recherche ne fonctionne pas pour mes visiteurs. Je n’ai pas de version tournant en local.

La table spip_index s’est bien créée et semble réaliste. Tous les mots de spip_index_dico sont en minuscules.

J’ai considéré tous les forums de votre site à la recherche de la BONNE solution, mais je reste perplexe devant la variété des cas et des solutions transitoires ou définitives proposées par mes collègues.

Ma qestion est simple, je suis très peu expérimenté en php, bien que comprenant le fonctionnement général de SPIP et la structure de ses tables et modules : Que dois-je faire pour que ça marche ?

Manar
16 janvier 2008 13:55
[RESOLU] pb moteur recherche sur spip 1.9.2c

Bonjour, j’ai migré vers 1.9.2c, et j’ai eu le même problème avec le moteur de recherche. j’ai vérifié dans la table d’indexation, y avait qlq mots indexés. j’ai téléchargé le plugin recherche_etendue_1_9 et j’ai forcé l’indexation—> rien !!!! les barres d’indexation étaient toutes vertes pourtant.

j’ai pensé à purger les tables (bouton tout en bas) et puis forcer l’indexation et...........ça a marchiiiiiiiii

bon courage !

3 mars 2008 10:35
>Problème fonction recherche étendue

Bonjour,

Nous sommes confrontés à un problème sur la fonction de recherche étendue après installation du plugin sur notre version 1.9.2d de spip (migration de version 1.8.2d à 1.9.2d après problème sur la fonction recherche).

L’outils fonctionne sur les pages d’administration du site, mais pas sur notre site de production, où nous obtenons le message d’erreur suivant après envoi d’une recherche :

Spip 1.9.2d debug Mon site SPIP

   * Error(s) in template
         o ُError in the site, } {0, 1}>
           <:changer_lang:> <:changer_lang:>
           <:recherche:>

           [(#FORMULAIRE_RECHERCHE)]
           <:sous_rubriques:>

               + [(#TITRE|supprimer_numero)]

[
<:recherche_sur:> '(#RECHERCHE)'
]

<:accueil:> > <:recherche_sur:> '#Recherche'
[(#TITRE|DeletePrefix|supprimer_numero|get_abbr)]

[(#DATE_MODIF|nom_jour)] [(#DATE_MODIF|affdate)]
<:documents:>

   * [(#TITRE|DeletePrefix|supprimer_numero|get_abbr)]


# ُError in the site, } {0, 1}>
<:changer_lang:> <:changer_lang:>
<:recherche:>

[(#FORMULAIRE_RECHERCHE)]
<:sous_rubriques:>

   * [(#TITRE|supprimer_numero)]

[
<:recherche_sur:> '(#RECHERCHE)'
]

<:accueil:> > <:recherche_sur:> '#Recherche'
[(#TITRE|DeletePrefix|supprimer_numero|get_abbr)]

[(#DATE_MODIF|nom_jour)] [(#DATE_MODIF|affdate)]
<:documents:>

   * [(#TITRE|DeletePrefix|supprimer_numero|get_abbr)]


# ُError in the site, } {0, 1}>
<:changer_lang:> <:changer_lang:>
<:recherche:>

[(#FORMULAIRE_RECHERCHE)]
<:sous_rubriques:>

   * [(#TITRE|supprimer_numero)]

[
<:recherche_sur:> '(#RECHERCHE)'
]

<:accueil:> > <:recherche_sur:> '#Recherche'
[(#TITRE|DeletePrefix|supprimer_numero|get_abbr)]

[(#DATE_MODIF|nom_jour)] [(#DATE_MODIF|affdate)]
<:documents:>

   * [(#TITRE|DeletePrefix|supprimer_numero|get_abbr)]


# ُError in the site, } {0, 1}>
<:changer_lang:> <:changer_lang:>
<:recherche:>

[(#FORMULAIRE_RECHERCHE)]
<:sous_rubriques:>

   * [(#TITRE|supprimer_numero)]

[
<:recherche_sur:> '(#RECHERCHE)'
]

<:accueil:> > <:recherche_sur:> '#Recherche'
[(#TITRE|DeletePrefix|supprimer_numero|get_abbr)]

[(#DATE_MODIF|nom_jour)] [(#DATE_MODIF|affdate)]
<:documents:>

   * [(#TITRE|DeletePrefix|supprimer_numero|get_abbr)]


# ُError in the site, } {0, 1}>
<:changer_lang:> <:changer_lang:>
<:recherche:>

[(#FORMULAIRE_RECHERCHE)]
<:sous_rubriques:>

   * [(#TITRE|supprimer_numero)]

[
<:recherche_sur:> '(#RECHERCHE)'
]

<:accueil:> > <:recherche_sur:> '#Recherche'
[(#TITRE|DeletePrefix|supprimer_numero|get_abbr)]

[(#DATE_MODIF|nom_jour)] [(#DATE_MODIF|affdate)]
<:documents:>

   * [(#TITRE|DeletePrefix|supprimer_numero|get_abbr)]

Merci.

Samuel BOIROT (Conseil Régional Rhône-Alpes)
4 mars 2008 14:59
>Fonction recherche incompatible avec mySQL 4.1.8

D’autre éléments pour approcher une solution... : Nous avons nous aussi rencontré ce problème (avec SPIP 1.9.1 et deux implémentations : en MySQL 5.0.32 ou 5.0.37).

Après recherches approfondies, nous avons découvert que SPIP émet, pour interroger la base, une requête qui invoque une clause "where hash in (valeur1, valeur2, ..., valeur n)".

Il se trouve que, dans l’une de nos implémentations, SPIP exprime les valeurs dans le IN en décimal, et dans l’autre en hexadécimal (commençant par un 0x). Et ça marche dans le second cas (si les valeurs du hash sont exprimées en base décimale) !

Après avoir interrogé un DBA, c’est normal que ça déraille en hexa, car dans une clause IN, MySQL attend une liste de valeur textuelles, donc il ne cherche pas à les convertir d’hexa en décimal.

La preuve : si on remplace la clause IN par une clause équivalente "hash=valeur1 or hash=valeur2,...", ça fonctionne parfaitement, même si les valeurs sont exprimées en hexa...

On approche donc de la cause. Toutefois, en l’état actuel de nos recherches, nous ne savons pas pourquoi SPIP exprime les valeurs en hexa sur une de nos implémentations, et pas sur l’autre... Nous soupçonnons un paramètre du noyau PHP, car la version SPIP étant la même, le problème n’est pas au sein du code SPIP...

Nous poursuivons nos recherches. En attendant, deux pistes de solutions :
- Retoucher le code SPIP (comme déjà indiqué dans les contribs ci-dessus), pour lui faire exprimer la requête en disant "hex(hash)=..."
- Bypasser totalement les fonctions de restitution de recherche SPIP, et écrire soi-même une requête d’interrogation qui tape dans les tables d’indexation, qui, elles sont justes !

A suivre...

4 mars 2008 15:15
>Fonction recherche incompatible avec mySQL 4.1.8

Cette méthode de recherche a été totalement abandonnée dans la version de développement. On a mis à la place une recherche "brute" dans l’ensemble des tables de la base de données, et un plugin "Indexation" s’occupe d’affiner tout ça.

Elijah
13 août 2008 13:31
>Fonction recherche incompatible avec mySQL 4.1.8

Connectez-vous en ssh, comptez le nombre d’objets à réindexer (articles, brèves, mots-clés, auteurs, etc), triplez le résultat que vous obtenez (pour être bien sûr) et exécutez apache bench :

« ab -n30000 -c5 http://chemin.du.site.com/backend.php3 »

(où 30000 est le nombre d’objets à indexer)

PS : ab=apache bench et le chemin ou path est souvent : /usr/local/apache/bin/ab

C’est sur http://geox.fr/?p=53

RSS






squelette