Re: Modification de la compilation de jointures en 3.1 ?

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)

-- 
RastaPopoulos