La raison de ce dépôt est que je mets à l'épreuve les api et les évolutions en réalisant le portage de plusieurs plugins pour la version 2.0.
Dans le cas présent, je me suis aperçu que la gestion de sous requêtes que j'avais introduites pour le critère {!id_mot=xx} était limitée à des sous requêtes simplifiées conçues comme une simple déclinaison de la requête principale.
Pour le portage d'accès restreint, et pour corriger un problème de performance, je suis amené à avoir besoin de générer un where avec une sous requête portant sur une autre table typiquement :
SELECT * FROM spip_forums where id_article IN (SELECT id_article FROM spip_articles WHERE id_rubrique NOT IN (1,2,3))
On peut pas écrire explicitement la sous requête dans la fonction critère en la mettant dans le ->where, car ensuite l'optimisation de calculer_select risque de se prendre les pieds dans le tapis en mélangeant la requête principale avec la sous requête.
On retient donc une forme raccourcie que calculer_select explicitera après son optimisation, pendant laquelle il aura ignoré la sous requête.
je suis amené à avoir besoin de générer un where avec une sous requête portant sur une autre table typiquement :
SELECT * FROM spip_forums where id_article IN (SELECT id_article FROM spip_articles WHERE id_rubrique NOT IN (1,2,3))
Cette construction est pratiquement offerte par la fonction d'abstraction sql_in_select, ligne 422 de base/abstract_sql
avec un commentaire sur comment intégrer ça au mieux des possibilités du serveur.
Quand tu dis:
c'est un commit mineur en terme de code
Une fois de plus le pb n'est pas là: c'est un gros commit en terme de spécification du langage intermédiaire utilisé par le compilateur.
Dans la documentation décrivant le serveur virtuel SQL il est dit que l'argument de Where est une chaîne, l'usage tableau étant réservé au compilateur.
Je préférerais qu'on se tienne à ça pour le moment
je suis amené à avoir besoin de générer un where avec une sous requête portant sur une autre table typiquement :
SELECT * FROM spip_forums where id_article IN (SELECT id_article FROM spip_articles WHERE id_rubrique NOT IN (1,2,3))
Cette construction est pratiquement offerte par la fonction d'abstraction sql_in_select, ligne 422 de base/abstract_sql
avec un commentaire sur comment intégrer ça au mieux des possibilités du serveur.
oui, tout a fait, au niveau de la couche d'abstraction c'est géré.
le problème se pose uniquement au niveau des clauses where compilées qui sont envoyées à calculer_select.
Comme cette fonction fait de l'optimisation de requêtes en se basant sur la présence ou non de certains termes dans les select, il est nécessaire qu'elle puisse distinguer les sous requêtes.
Quand tu dis:
c'est un commit mineur en terme de code
Une fois de plus le pb n'est pas là: c'est un gros commit en terme de spécification du langage intermédiaire utilisé par le compilateur.
je comprends, je veux bien qu'on la note comme expérimentale avec le risque que cela comporte.
Dans la documentation décrivant le serveur virtuel SQL il est dit que l'argument de Where est une chaîne, l'usage tableau étant réservé au compilateur.
ok, j'ai corrigé.
Les arguments ne sont pas directement envoyes a sql_select, mais repassent dans calculer_select pour optimiser eventuellement la sous requete, mais une chaine passera aussi maintenant.