Suite au travail posté ici le 16 Octobre pour limiter les requêtes SQL aux champs
effectivement utilisés, voici une nouvelle version du
compilateur de squelettes et ses innovations :
- tout champ SQL est reconnu comme paramètre d’une boucle SPIP ;
- les paramètres comme {1,n-1} où n désigne le nombre d’éléments
issus de la requête (voir les spécifications) sont reconnus.
En ce qui concerne le premier point, le principe de base a consisté à extraire du
fichier ecrire/inc_base la description des tables SQL et d’en faire des tableaux PHP
à présent déclarés dans un nouveau fichier nommé écrire/inc_kreate. Ce fichier
est lu par inc_base pour créer les tables SQL comme auparavant, mais est également lu par inc-calcul-squel pour connaître les champs existant dans chaque
table. Ces tableaux remplacent donc les tableaux $rows_* homonymes (qui figuraient dans inc-champ-squel) qui en étaient en fait des versions réduites.
Ainsi, cette nouvelle version du compilateur a pour effet que l’ajout d’un champ
dans une table SQL sera automatiquement répercuté dans l’analyse des paramètres
(entre autres le champ URL_REF que j’avais oublié dans la version précédente).
On peut débrayer cet automatisme en ajoutant des éléments au tableau
$exceptions_des_tables (si les noms des champs et/ou des tables SQL ne sont pas
les homonymes SPIP) ou au
tableau $exceptions_des_champs (si l’on veut implanter un traitement ultra-spécifique
dans l’aiguillage de inc-index-squel malgré l’homonymie). C’est ce qui a été fait
pour les qq cas existants actuellement (par exemple le champ faussement homonyme « LESAUTEURS » , et les synonymes « id_secteur/id_rubrique »
dans la table « breves »). A l’inverse,
les tableaux $contextes et $tables_doublons ont disparu car désormais inutiles.
Cette simplification a débouché sur l’élimination de la plupart des « AS » dans les
requetes SQL ; on peut les remettre éventuellement mais je n’ai pas vu l’intérêt
d’alourdir le code avec une telle gestion dans ce cadre.Le fichier spip_log est un peu plus verbeux lors des créations de tables, afin de repérer
plus facilement une éventuelle faute dans leur déclaration.
Je signale par ailleurs un bizarrerie : les 2 appels à la fonction maj_base attendent de celle-ci un résultat booléen, mais cette fonction ne contient aucun return dans sa définition, et retourne donc toujours faux. Je suis
tombé sur le pb dans mes essais de recréation de la base à l’aide des tableaux PHP,
et je l’ai résolu en rajoutant un « return true » final car je n’ai pas réussi à comprendre
le rôle de ce booléen. Il faudrait tirer ça au clair.
Bonne expérimentation à tous !
Aucune discussion
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires : |