[spip-dev] Aïe, vilain bug sur les boucles et les jointures si le prefixe de table n'est pas 'spip'

Bonjour,

En 1.9.3, s'il y a dans un squelette (en l'occurrence 'gribouille' ici)
<BOUCLE_(spip_versions)...> ou <BOUCLE_(spip_versions spip_articles)...> ou <BOUCLE_(VERSIONS spip_articles)...> bref, un spip_ qui traine dans le nom de la table, il devrait être remplacé par le vrai préfixe de table de SPIP. Or, il semble que ça ne le fasse pas.

Donc, si mon préfixe de table est différent de 'spip', j'ai des "Table SQL « spip_versions » inconnue" qui me reviennent.

J'arrive à corriger, (mais le problème n'est peut être pas ici) et j'ai un gros doute quand à ma proposition qui entre autre supprime le nom de la base sql (pour qu'une requete SHOW TABLE LIKE 'x' se déroule correctement car il ne trouve pas SHOW TABLE LIKE '`base`.table' de ce que je crois comprendre.)

La deuxième chose est la petite étoile, ou un ? pour dire que la virgule n'est pas obligatoire, sinon, la première table passée (pour les jointures) n'a pas son nom de corrigé.

Je n'ai pas regardé en PG si ces boucles passaient ou non.

MM.

Index: req/mysql.php

Matthieu Marcillaud a écrit :

Bonjour,

En 1.9.3, s'il y a dans un squelette (en l'occurrence 'gribouille' ici)
<BOUCLE_(spip_versions)...> ou <BOUCLE_(spip_versions spip_articles)...>

Donc, si mon préfixe de table est différent de 'spip', j'ai des "Table SQL « spip_versions » inconnue" qui me reviennent.

Je n'ai pas regardé en PG si ces boucles passaient ou non.

Idem en PG.

MM.

La convention c'est que le contenu de la parenthèse après "<BOUCLE..." contient soit des abréviations des tables prédéfinies de SPIP (donc sans préfixe), soit des noms SQL complets. Il n'y a pas de raison d'écrire "spip_articles" quand on peut écrire "articles", sauf justement à vouloir référencer une table "spip_articles" qui serait co-locataire dans une même base de données avec une table "articles" qui aurait un autre préfixe. C'est un peu contre-intuitif, mais c'est le poids de l'histoire mélangé au fait de pouvoir faire des jointures entre tables de sites co-locataires.

Committo,Ergo:Sum

Committo,Ergo:sum a écrit :

En 1.9.3, s'il y a dans un squelette (en l'occurrence 'gribouille' ici)
<BOUCLE_(spip_versions)...> ou <BOUCLE_(spip_versions spip_articles)...>
ou <BOUCLE_(VERSIONS spip_articles)...> bref, un spip_ qui traine dans
le nom de la table, il devrait être remplacé par le vrai préfixe de
table de SPIP.

La convention c'est que le contenu de la parenthèse après "<BOUCLE..." contient soit des abréviations des tables prédéfinies de SPIP (donc sans préfixe), soit des noms SQL complets.

Admettons, mais <BOUCLE_(VERSIONS spip_articles)...> ne passe pas non plus :frowning: !

<BOUCLE_revisions(VERSIONS spip_articles){id_rubrique}{par date}{inverse}{pagination 25}{statut=publie}>

<li>
[(#SET{gras,[(#ID_ARTICLE|unique|?{b})]})]
...#URL_ARTICLE
...#ID_VERSION
...#TITRE
...#DATE|date_relative
</BOUCLE_revisions>

Erreur sur le site boucle critère inconnu id_rubrique
2 Erreur sur le site boucle critère inconnu statut
3 <BOUCLE_revisions>()
Erreur SQL
versions.date, versions.id_article, versions.id_version, versions.id_auteur FROM spip_versions AS `versions` WHERE (id_rubrique = '1') AND (statut = 'publie') ORDER BY versions.date DESC
Unknown column 'id_rubrique' in 'where clause'
</BOUCLE_revisions>

MM.

On doit pouvoir se débrouiller avec la globale $tables_jointures.
Mais si on veut garder la compatibilité tout ça sera toujours bancal.

Committo,Ergo:Sum

Committo,Ergo:sum a écrit :

Non, ici "spip_articles" est vue comme une table SQL sans rapport avec SPIP a priori. Si elle existe, ça marche, sinon ça marche pas, c'est dans la logique de la spec.

Committo,Ergo:Sum

Committo,Ergo:sum a écrit :