* cedric.morin@yterium.com tapuscrivait, le 24/04/2010 18:36:
* RealET tapuscrivait, le 19/04/2010 13:27:
Bonjour,
Sur un site que je viens de passer de 2.0.10 à 2.1, avec mediathèque en
extensions/ j'ai l'erreur suivante sur une page de rubrique contenant un
document appelé dans le texte de la rubrique :
ecrire/?exec=naviguer&id_rubrique=14&var_mode=recalcul
Table SQL « spip_documents_liens » inconnue
.../extensions/indispensable/gestion_documents/modeles/document_desc.html _compte
36
Hormis cette erreur, la page s'affiche normalement.
Résolu par Connexion · GitLab
Heu non.
On ne déclare pas en table_des_tables une table auxiliaire de liaison entre tables.
Et par ailleurs un simple
documents_liens en minuscule aurait suffi, il me semble.
Le problème, c'est que les modifications faites par ESJ sur le compilateurs font que :
- spip_nomdetable n'est plus remplacé par prefix_nomdetable
- si une table n'est pas déclarée dans les tables connues de SPIP, alors, c'est le nom_table en tenant compte de la casse qui est utilisé
Tu as essayé documents_liens en minuscules, ou tu supposes juste que ça marche pas ?
Moi il me semble bien que ça marche et que c'est la bonne façon de l'écrire.
Du coup, pour ce que j'en ai compris, le seul moyen de faire une boucle sur une table qui peut être préfixée par spip_ ou ce qui est déclaré dans la config du site, c'est de la déclarer.
Au passage, ça donne une incohérence entre :
- le code php de SPIP qui avec les requêtes remplace systématiquement spip_ par le préfixe déclaré
- les boucles qui même lorsque le nom dans la boucle est spip_matable ne font plus le remplacement de prefixe.
Oui, il y a clairement une incohérence là que j'ai vue il y a peu.
Même si on a un prefixe truc_, on ne peut de toute façon pas interroger une table "externe" spip_xxx car le sql_select rempacera spip_ par "truc_"
Du coup il serait effectivement cohérent que "spip_xxx" soit toujours implicitement compris comme devant etre remplacé par le prefixe.
Cédric
* cedric.morin@yterium.com tapuscrivait, le 24/04/2010 22:20:
Le 24 avr. 2010 à 20:45, RealET a écrit :
* cedric.morin@yterium.com tapuscrivait, le 24/04/2010 18:36:
Le 24 avr. 2010 à 16:15, RealET a écrit :
* RealET tapuscrivait, le 19/04/2010 13:27:
Bonjour,
Sur un site que je viens de passer de 2.0.10 à 2.1, avec mediathèque en
extensions/ j'ai l'erreur suivante sur une page de rubrique contenant un
document appelé dans le texte de la rubrique :
ecrire/?exec=naviguer&id_rubrique=14&var_mode=recalcul
Table SQL « spip_documents_liens » inconnue
.../extensions/indispensable/gestion_documents/modeles/document_desc.html _compte
36
Hormis cette erreur, la page s'affiche normalement.
Résolu par Connexion · GitLab
Heu non.
On ne déclare pas en table_des_tables une table auxiliaire de liaison entre tables.
Et par ailleurs un simple
documents_liens en minuscule aurait suffi, il me semble.
Le problème, c'est que les modifications faites par ESJ sur le compilateurs font que :
- spip_nomdetable n'est plus remplacé par prefix_nomdetable
- si une table n'est pas déclarée dans les tables connues de SPIP, alors, c'est le nom_table en tenant compte de la casse qui est utilisé
Tu as essayé documents_liens en minuscules, ou tu supposes juste que ça marche pas ?
Je n'avais pas essayé (j'y croyais pas).
Je viens d'essayer, ça marche !
Par contre, là où ça devient sioux, c'est que :
(DOCUMENTS spip_ documents_liens) et (DOCUMENTS documents_liens) donnent tous les 2 la bonne requête avec le bon prefixe.
(je précise que dans ma base, il n'y a aucune table spip_documents_liens)
Moi il me semble bien que ça marche et que c'est la bonne façon de l'écrire.
Du coup, pour ce que j'en ai compris, le seul moyen de faire une boucle sur une table qui peut être préfixée par spip_ ou ce qui est déclaré dans la config du site, c'est de la déclarer.
Au passage, ça donne une incohérence entre :
- le code php de SPIP qui avec les requêtes remplace systématiquement spip_ par le préfixe déclaré
- les boucles qui même lorsque le nom dans la boucle est spip_matable ne font plus le remplacement de prefixe.
Oui, il y a clairement une incohérence là que j'ai vue il y a peu.
Même si on a un prefixe truc_, on ne peut de toute façon pas interroger une table "externe" spip_xxx car le sql_select rempacera spip_ par "truc_"
Du coup il serait effectivement cohérent que "spip_xxx" soit toujours implicitement compris comme devant etre remplacé par le prefixe.
Cédric