en 1.9 il était indiqué qu'on pouvait rechercher dans les tables supplémentaires si celles çi avait un champ idx.
Problème en 2.0 la recherche ne repose plus sur ce champs idx.
J'essaie pour ma part d'afficher dans les résultats obtenus via le moteur de recherche spip les billets d'un blog dotclear.
Je fais donc naïvement :
<BOUCLE_dc(mabase_dotclear2:DC_POST){recherche}{post_status=1}>
mabase_dotclear2 correspond au nom du fichier de connexion, DC_POST à la table des billets, et post_status=1 les billets publiés
mais j'ai comme erreurs :
Erreur SQL
UNIX_TIMESTAMP(NOW())-UNIX_TIMESTAMP(maj) AS fraicheur FROM spip_resultats WHERE recherche='7a92637c91357c7e' ORDER BY fraicheur DESC LIMIT 0,1
Table '(mabase_dotclear2.spip_resultats' doesn't exist
<BOUCLE_dc>()
Erreur SQL
dc_post.post_id, resultats.points AS points, dc_post.post_url, dc_post.post_title FROM dc_post AS `dc_post` INNER JOIN spip_resultats AS resultats ON ( resultats.id = dc_post.post_id ) WHERE recherche='7a92637c91357c7e' AND (dc_post.post_status = '1')
Table '(mabase_dotclear2.spip_resultats' doesn't exist
</BOUCLE_dc>
en 1.9 il était indiqué qu'on pouvait rechercher dans les tables
supplémentaires si celles çi avait un champ idx.
On parle d'une *table* supplémentaire ;
Dans ce cas, il faut declarer les champs utilisables pour la recherche dans le pipeline ad hoc
dans ton exemple tu es dans
une *base* extérieure, et là le critère {recherche} ne marche pas.
Oui, d'ailleurs c'est un cas non prévu et non testé, mais qui merite un ticket.
L'erreur est qu'on veut stocker les resultats sur la base distante, alors qu'il faudrait chercher sur la base distante, mais stocker les resultats sur la base locale.
Mais cela empecherait probablement toute jointure, donc contourner par un IN () explicite ...
A suivre, donc
Cedric
