me promenant de-ci de-là, je découvre de subtiles différences
de traitement pour les boucles suivant le nom que je donne
aux tables concernées.
ainsi :
<BOUCLE_a(ARTICLES)...>
sql généré :
SELECT articles.id_article, articles.lang
FROM spip_articles AS `articles`
WHERE (articles.statut = 'publie')
<BOUCLE_a(articles)...>
sql généré :
SELECT articles.id_article, articles.lang
FROM spip_articles AS `articles`
WHERE (articles.statut = 'publie')
<BOUCLE_a(spip_articles)...>
sql généré :
SELECT articles.id_article
FROM spip_articles AS `articles`
ou encore :
<BOUCLE_a(AUTEURS)...> (tout comme <BOUCLE_a(auteurs)...>)
sql généré :
SELECT auteurs.id_auteur
FROM spip_auteurs AS `auteurs`
INNER JOIN spip_auteurs_articles AS L1
ON ( L1.id_auteur = auteurs.id_auteur )
INNER JOIN spip_articles AS L2
ON ( L2.id_article = L1.id_article )
WHERE (auteurs.statut != '5poubelle')
AND (L2.statut = 'publie')
GROUP BY auteurs.id_auteur
<BOUCLE_a(spip_auteurs)...>
sql généré :
SELECT auteurs.id_auteur
FROM spip_auteurs AS `auteurs`
ce comportement en cas de nommage de la table
préfixe + bas-de-casse m'intéresse.
ma question (enfin !) :
est-ce amené à changer ?
faut-il documenter ?
comportement testé sur 2.1.0dev SVN[14465]
et sur 2.0.9 SVN [14465]
C'est exactement l'objet de la discussion que le commit de kent1 a
fait remonter.
Il existe des tables nommées toto, TOTO et spip_toto, et la
boucle(TOTO) peut, ou pas, adresser chacune de ces tables. Au départ
c'était uniquement pour les spip_toto de SPIP, maintenant c'est pour
les spip_toto *officiels* de SPIP, ce qui signifie que les boucles
définies dans les plugins n'y auraient plus droit. Donc rupture de
compatibilité ascendante chaque fois qu'un truc sort du core pour
passer en plugin. On doit pouvoir faire mieux que ça
C'est exactement l'objet de la discussion que le commit de kent1 a
fait remonter.
Il existe des tables nommées toto, TOTO et spip_toto, et la
boucle(TOTO) peut, ou pas, adresser chacune de ces tables. Au départ
c'était uniquement pour les spip_toto de SPIP, maintenant c'est pour
les spip_toto *officiels* de SPIP,
non, non, pour ceux declaré dans table_des_tables donc les plugins peuvent aussi en profiter, il me semble
Il existe des tables nommées toto, TOTO et spip_toto, et la
boucle(TOTO) peut, ou pas, adresser chacune de ces tables.
pour ceux declaré dans table_des_tables donc les plugins peuvent aussi en profiter, il me semble
j'entends bien.
ma question est :
la requête sql générée par ce nommage particulier :
prefixe_table en bas-de-casse est-elle appelée à changer ?
indépendamment de savoir quelles sont (seront)
les tables concernées.
manifestement, nommer ainsi une table lui fait perdre
les clauses where ($boucle->where) défines par défaut,
et en dur, dans ecrire/public/boucles.php
(sachant, bien sûr, que les clauses where construites à partir
des critères passés explicitement aux boucles de ce type sont
bien générées et prises en compte...)
la requête sql générée par ce nommage particulier :
prefixe_table en bas-de-casse est-elle appelée à changer ?
Ah tu parles de BOUCLE(spip_articles) ; là, en effet, on initialise
dans boucle_defaut() et pas dans boucle_ARTICLES(), et donc il n'y a
pas de controle du statut. A mon sens ça ne devrait pas changer.
El Saturday 05 September 2009 09:03:22 denisb va escriure:
me promenant de-ci de-là, je découvre de subtiles différences
de traitement pour les boucles suivant le nom que je donne
aux tables concernées.
ainsi :
[...]
Je voulais demander pour le coup du statut de publication, et dans une
moindre mesure la langue dans le select, du coup peut-être que c'est pas
grave, mais c'est la bonne occasion.
