Il me semble qu'Emmanuel a changé dans SPIP la gestion de la casse des
appels à BOUCLE(TOTO) qu'il faudrait désormais écrire BOUCLE(toto).
Ca casse un nombre important de choses dans certains squelettes et
plugins, y compris je crois des plugins comme agenda ou messagerie.
C'est peut-être ça qu'il faut revoir car le but n'était que
d'accomoder certains cas très particuliers sur postgre, de tables
nommées en CamelCase ou autre. On pourrait faire une première passe
avec l'ancienne règle, et si elle ne donne pas de résultat, faire une
seconde vérif en préservant la casse.
Je pense qu'il faut être plus smart : si on ne trouve pas la table,
regarder si elle existe avec une autre casse que celle qui est
indiquée dans la boucle. Ainsi sauf cas extraordinaire où deux tables
porteraient le même nom avec des casses différentes, boucle(TOTO) et
boucle(Toto) donneraient toujours la table toto, ou Toto, ou toTo (ou
spip_toto).
mais je vais peut-être laisser Emmanuel faire le truc car c'est "délicat"
Pour résumer la discussion, je trouve normal que SPIP privilégie une interface intuitive avec
les services massivement utilisé que sont MySQL et consorts,
plutôt que de privilégier une compatibilité avec ses propres extensions,
qui n'ont pas un taux d'utilisation comparable.
Il me semble qu’Emmanuel a changé dans SPIP la gestion de la casse des
appels à BOUCLE(TOTO) qu’il faudrait désormais écrire BOUCLE(toto).
Ca casse un nombre important de choses dans certains squelettes et
plugins, y compris je crois des plugins comme agenda ou messagerie.
C’est peut-être ça qu’il faut revoir car le but n’était que
d’accomoder certains cas très particuliers sur postgre, de tables
nommées en CamelCase ou autre.
Pour résumer la discussion, je trouve normal que SPIP privilégie une interface intuitive avec
les services massivement utilisé que sont MySQL et consorts,
plutôt que de privilégier une compatibilité avec ses propres extensions,
qui n’ont pas un taux d’utilisation comparable.
Le problème que j’ai tant bien que mal essayé de corrigé n’est pas uniquement lié à ce plugin … Il peut se reproduire par la suite avec d’autres certainement …
Le problème était que find_in_path me cherchait un fichier connect/XXX.php et que mon serveur n’est pas foutu de prendre connect/xxx.php pour le même fichier et qu’il me semble mieux d’avoir une homogénéité dans le nommage des fichiers que de jouer avec des casses différentes…
J’aurais pu simplement renomme connect/pour.php en connect/POUR.php mais la source d’erreur incompréhensible aurait pu être là pour d’autres cas et on aurait couru derrière car chez les uns ca marche, chez les autres non …
ah merci, je ne retrouvais pas la discussion, que j'avais survolée
Pour résumer la discussion, je trouve normal que SPIP privilégie une
interface intuitive avec
les services massivement utilisé que sont MySQL et consorts,
plutôt que de privilégier une compatibilité avec ses propres extensions,
qui n'ont pas un taux d'utilisation comparable.
tu sembles dire que les choses s'opposent, mais on devrait pouvoir les
résoudre simultanément en ayant un deuxième regard si la table
n'existe pas dans la casse demandée, mais existe dans une autre
casse... non ?
Possible, mais les plugins de SPIP n'ayant pas une documentation intégrée,
contrairement aux serveurs SQL, je ne vois pas sur quoi m'appuyer pour écrire du code qui satisfasse tout le monde.
n'existe pas dans la casse demandée, mais existe dans une autre
casse... non ?
Possible, mais les plugins de SPIP n'ayant pas une documentation intégrée,
contrairement aux serveurs SQL, je ne vois pas sur quoi m'appuyer pour
écrire du code qui satisfasse tout le monde.
Je pense qu'il faut être plus smart : si on ne trouve pas la table,
regarder si elle existe avec une autre casse que celle qui est
indiquée dans la boucle. Ainsi sauf cas extraordinaire où deux tables
porteraient le même nom avec des casses différentes, boucle(TOTO) et
boucle(Toto) donneraient toujours la table toto, ou Toto, ou toTo (ou
spip_toto).
OK après enquête le point bloquant n'était en fait *pas du tout* dans
le compilo, mais dans la fonction showtable de req/mysql.php, qui pour
savoir si une table existe fait ceci :
spip_mysql_query("SHOW TABLES LIKE '$nom_table'")...
Or si ma table s'appelle "Toto", les deux requetes suivantes échouent :
SHOW TABLES LIKE 'TOTO';
SHOW TABLES LIKE 'toto';
Le LIKE ici est fait en BINARY, et pas moyen d'inverser.
Mais comme ce test est inutile (!), je l'enlève et du coup les boucles
(TOTO), (toto) et (Toto) donnent le même résultat...