Re: Modification de la compilation de jointures en 3.1 ?

Un récent log témoigne des ténébreuses circonvolutions du moteur de jointure :
<< Boucler directement sur la table GIS_LIENS et non GIS gis_liens sans quoi SPIP 3.1 ajoute un GROUP BY L1.id_gis à la 
requête SQL, ce qui n'affiche qu'un seul objet lié >>

Un tel usage de la casse me laisse perplexe.
Si vous ne voyez pas ce que je veux dire, imaginez vous une boucle dont le fonctionnement changerait
selon que son nom comporte un nombre pair ou impair de voyelles ?

Plus généralement, c'est souvent à tâton que je fais la recherche de la bonne jointure.

J'ai l'impression que la montée en puissance de l'intelligence des jointures
ne s'est pas accompagnée de l'interface qui permettrait de s'en servir facilement.

C'est devenu comme un moteur de formule 1 dans une carrosserie de 2 chevaux
avec les manettes d'un jouet téléguidé 3-5 ans.

L'interface qui révélerait et rendrait accessible cette puissance, ce serait
une mise à plat (oulala) au moins conceptuelle, l'invention éventuelle
de nouveaux éléments de langage (= lexicaux ou grammaticaux)
qui structureraient le code et rendraient les fonctionnalités plus aisément accessibles...
et finalement une documentation.

JLuc


Le 08/02/2016 11:22, RastaPopoulos a écrit :
> Le 08/02/2016 10:23, Cédric Morin a écrit :
>> 6/ si tu as bien suivi tu comprends ce qui se passe :
>> - le compilateur crée la boucle avec jointure sur spip_auteurs
>> - il voit un #ID_OBJET dans le corps de la boucle
>> - il cherche le champ dans la requete SQL et le trouve sur la table
>> auteurs_liens
>> - lors de l'execution sans id_auteur dans le env, la jointure
>> auteurs_liens est conservée car elle sert pour le champ #ID_OBJET
>
> Ok, merci Cédric, je comprends beaucoup mieux !
>
> Mais du coup, l'ordre de priorité ne me parait pas du tout logique.
>
>> Peut-être que la solution serait de modifier le sens des jointures
>> explicites pour lui donner celui que tu suppose : une jointure que l'on
>> force, explicitement, avant toute autre analyse de la boucle, quitte à
>> ce qu'elle soit optimisée ensuite si elle ne sert pas.
>> Mais c'est une modification non mineure a tester en 3.2-dev
>
> Et donc effectivement, je pense que la solution (ou une des solutions), c'est déjà que les jointures *prioritaires*
> soient celles proposées dans la définition de la boucle (entre parenthèses), *avant* celles possibles par les critères
> (accolades).
>
> Car en tant que dev de squelettes, cela parait plus logique que ce qu'on a proposé en premier… soit utilisé en premier.
> D'autant que là ce n'est même pas juste une question d'ordre : mais aussi de sens, car la première utilisation est dans
> la définition du type de boucle. Intuitivement prioritaire à mon avis.
>
>> Je vais reflechir aux possibilités, côté compilateur, mais en attendant
>> je vois deux solutions :
>
> En attendant j'ai pour le moment viré le critère d'auteurs, qui pour l'instant n'était pas utilisé dans des inclusions
> de la liste des "sélections liées à des contenus".
>
> Mais à terme on pourrait imaginer que sur les pages des comptes utilisateurs, on affiche les sélections qu'ils gèrent,
> donc oui il faudra trouver une solution dans ce cas.
>
> Encore merci…
> (mais à suivre car pas résolu pour de vrai)
>