Indexer : La boucle SPHINX - commentaires

Indexer : La boucle SPHINX

@maieul : oui en local j'ai la version 2.2.9. Donc c'est résolu dans les versions postérieures, ticket fermé !

Indexer : La boucle SPHINX

Ok donc ça a l'air d'être côté Sphinx en fait

Indexer : La boucle SPHINX

@Tcharlss : qu'elle est ta version de SPHINX ?

La version locale que j'ai est 2.2.11 -> cela marche.
La version distante est 2.2.9 -> cela ne marche pas.

Et le ticket http://sphinxsearch.com/bugs/view.php?id=2375 dit que le problème a été résolue en 2.2.11.

Indexer : La boucle SPHINX

@Rastapopoulos : si le pb était un mélange int/string, comment ce ferait-il que la second requête Tcharlss, avec un IN, fonctionne ?

@Tcharlss : tu est sur que ton 'id_objet' contient « mots » ? ca devrait pas être un numéro plutot ?

Indexer : La boucle SPHINX

Ah mais je raconte n'importe quoi, tu as raison, ça marche bien.
J'avais mal vérifié, désolé pour le bruit !

Indexer : La boucle SPHINX

Moi j'ai l'impression que c'est parce que dans votre base il y a des valeurs en string, ou un mélange de valeurs string et int, non ? Et il peut pas faire la comparaison du coup ?

En effet pour moi il y a un mélange de int et de string.
C'est l'objet « hierarchie » qui est en string → [(#PROPERTIES|var_dump)] :

array (size=4) 'objet' => string 'hierarchie' (length=10) 'id_objet' => string 'mots' (length=4)

Indexer : La boucle SPHINX

la requete (qui marche en local mais pas sur mon site distant) :

SELECT *, WEIGHT() AS score, (properties.objet='article') as mono_0, (properties.parents.ids[0]=1) as mono_1, SNIPPET(content, 'rigolo', 'limit=200','html_strip_mode=strip') AS snippet FROM spip WHERE (mono_0=1) AND (mono_1=1) AND (MATCH('rigolo')) LIMIT 0,10

Indexer : La boucle SPHINX

non, j'ai bien vérifié ces points : la requete interroge un int, et j'ai en base un int (en tout cas, [(#PROPERTIES|var_dump)] me montre un int.

Indexer : La boucle SPHINX

Euh, comment ça se fait ? Parce que justement timestamp, c'est pareil : les dates les plus vieilles ont un nombre plus petit, donc si on classe par ordre croissant « par date », ça fait bien du plus vieux au plus récent à priori.

Indexer : La boucle SPHINX

Moi j'ai l'impression que c'est parce que dans votre base il y a des valeurs en string, ou un mélange de valeurs string et int, non ? Et il peut pas faire la comparaison du coup ?

Indexer : La boucle SPHINX

Merci ! J'ai exactement le même problème (avec id_rubrique).

Mais le truc bizarre est que cela ne le fait que sur le serveur distant, pas sur le site local, où ma requete fonctionne parfaitement.

Ca dépend peut être de la version de SPHINX, et dans ce cas ce serait un bug de SPHINX.

Je vais tester avec filtermultijson dès que possible.

Indexer : La boucle SPHINX

Hop, dans ma lancée, un autre bug rencontré avec le critère {filtermono}. Soit la boucle :

Quand il y a un id_objet dans l'environnement, ça ne marche pas.

Requête SQL :

SELECT *, (properties.id_objet=230) as mono_0 FROM truc WHERE (mono_0=1)

Erreur SQL :

ERROR 1064 (42000): index truc: parse error: equal operation applied to part string operands

En revanche, avec le critère {filtermultijson}, ça fonctionne bien :

Requête SQL :

SELECT *, (IN(properties.id_objet, 230)) as multi_0 FROM truc WHERE (multi_0=1)

Indexer : La boucle SPHINX

Un petit détail qui pourrait être mentionné dans la doc : les dates sont au format timestamp, donc pour trier sur ce critère il faut faire à l'inverse des boucles « traditionnelles » :

* du plus récent au plus ancien : {par date}
* du plus ancien au plus récent : {!par date}

Indexer : La boucle SPHINX

Un truc un peu surprenant qui devrait être mentionné dans la doc : sans le critère {pagination}, la boucle ne retourne que 20 résultats, même avec l'option max_matches.

Donc pour afficher tous les résultats il faut ajouter un truc du genre {pagination 999999}

Indexer : La boucle SPHINX

Bonjour,

Je rencontre un drôle de problème, comme si des critères de la boucle étaient mis en cache.

J'ai donc une saisie personnalisée utilisée dans un formulaire, elle contient une boucle SPHINX avec un critère {filtermultijson} qui doit être optionnel, donc pris en compte uniquement s'il y a rubriques dans l'environnement :

Cette saisie est inclue plusieurs fois dans mon formulaire, et je ne veux une restriction par rubriques que dans la 1^re :

$saisies = array( array( 'saisie' => 'masaisie', 'options' => array( 'nom' => 'test1', 'rubriques' => array(50), ), ), array( 'saisie' => 'masaisie', 'options' => array( 'nom' => 'test2', 'rubriques' => '', ), ), array( 'saisie' => 'masaisie', 'options' => array( 'nom' => 'test3', 'rubriques' => '', ), ),
);

Et là surprise, la restriction par rubriques est appliquée dans les 3 boucles !

Dans la méthode runQuery(), j'ai fait un var_dump($result['query']['query']); pour voir ce qu'il se passait.
Et effectivement, dans les 3 requêtes on retouve la même valeur dans le SELECT :

requête 1 : (IN(properties.rubriques.ids, 50)) (ok)
requête 2 : (IN(properties.rubriques.ids, 50)) (pas ok)
requête 3 : (IN(properties.rubriques.ids, 50)) (pas ok)

En revanche quand je donne explictement des valeurs à rubriques pour chaque saisie, elles sont correctement prises en compte. Par exemple en donnant respectivement 50, 100 et 150 :

requête 1 : (IN(properties.rubriques.ids, 50)) (ok)
requête 2 : (IN(properties.rubriques.ids, 100)) (ok)
requête 3 : (IN(properties.rubriques.ids, 150)) (ok)

Donc on dirait que ça prend automatiquement une valeur si la boucle est utilisée plusieurs fois, et qu'il n'y a pas de valeur donnée explicitement.

Enfin, si je ne donne une valeur 100 qu'à la 2^e saisie, j'obtiens ces requêtes :

requête 1 : rien (ok)
requête 2 : (IN(properties.rubriques.ids, 100)) (ok)
requête 3 : (IN(properties.rubriques.ids, 100)) (pas ok)

Donc ça semble ne remplir la valeur que s'il y en a une dans la boucle précédente.

Pour finir, si je fais des copies des squelettes de ma saisie avec des noms différents, là ça fonctionne correctement.
Bref, on dirait qu'il y a un espèce de cache quelque part qui entre en jeu.