je veux ré-écrire certains de mes plugins pour qu'ils puissent fonctionner sur un serveur proposant la mutualisation du noyau.
Ces plugins utilisent des tables spécifiques dans la base de données qui ont pour l'instant un nom fixe.
Pour adapter ces tables à la mutualisation, je suppose qu'il faut que j'ajoute une sorte de préfixe à mes noms de tables.
Quelqu'un aurait-il un exemple à me proposer ou une explication rapide sur la variable prefixe à ajouter ?
je veux ré-écrire certains de mes plugins pour qu'ils puissent fonctionner sur un serveur proposant la mutualisation du noyau.
Ces plugins utilisent des tables spécifiques dans la base de données qui ont pour l'instant un nom fixe.
Pour adapter ces tables à la mutualisation, je suppose qu'il faut que j'ajoute une sorte de préfixe à mes noms de tables.
Quelqu'un aurait-il un exemple à me proposer ou une explication rapide sur la variable prefixe à ajouter ?
Bon, je pense avoir trouvé : il faut rajouter $GLOBALS['table_prefix'] devant les noms des tables.
Quelqu'un peut confirmer ?
le mieux, c'est d'utiliser les fonctions de abstract_sql: http://doc.spip.org/@@abstract_sql.php
elles te donnent la couche d'abstraction sur la mutualisation, mais
aussi sur le type de base utilisé (puisqu'au final, ça devrait aussi
marcher avec postgre si j'ai bien suivit).
Sinon, si tu fais des requettes en dur, parce qu'elle ne sont pas dans
abstract_sql, tu dois au minimum faire quelque chose comme:
spip_query("ALTER TABLE `".$GLOBALS['table_prefix']."_auteurs` ADD
(`flickr_token` TINYTEXT NULL, `flickr_nsid` TINYTEXT NULL);");
Pierre
On 10/7/07, Olivier Gautier <olivier.gautier@ac-rouen.fr> wrote:
Olivier Gautier a écrit :
> Bonjour,
>
> je veux ré-écrire certains de mes plugins pour qu'ils puissent
> fonctionner sur un serveur proposant la mutualisation du noyau.
> Ces plugins utilisent des tables spécifiques dans la base de données
> qui ont pour l'instant un nom fixe.
>
> Pour adapter ces tables à la mutualisation, je suppose qu'il faut que
> j'ajoute une sorte de préfixe à mes noms de tables.
> Quelqu'un aurait-il un exemple à me proposer ou une explication rapide
> sur la variable prefixe à ajouter ?
Bon, je pense avoir trouvé : il faut rajouter $GLOBALS['table_prefix']
devant les noms des tables.
Quelqu'un peut confirmer ?
Sinon, si tu fais des requettes en dur, parce qu'elle ne sont pas dans
abstract_sql, tu dois au minimum faire quelque chose comme:
spip_query("ALTER TABLE `".$GLOBALS['table_prefix']."_auteurs` ADD
(`flickr_token` TINYTEXT NULL, `flickr_nsid` TINYTEXT NULL);");
Non pas du tout : spip_query("ALTER TABLE spip_articles...") sera
traduit correctement avec le bon préfixe de table ; en d'autres
termes, il n'y a rien à faire, c'est entièrement géré par
spip_query().
Le 07/10/07, Olivier Gautier<olivier.gautier@ac-rouen.fr> a écrit :
Bonjour Fil,
Fil a écrit :
>> Sinon, si tu fais des requettes en dur, parce qu'elle ne sont pas dans
>> abstract_sql, tu dois au minimum faire quelque chose comme:
>> spip_query("ALTER TABLE `".$GLOBALS['table_prefix']."_auteurs` ADD
>> (`flickr_token` TINYTEXT NULL, `flickr_nsid` TINYTEXT NULL);");
>>
>
> Non pas du tout : spip_query("ALTER TABLE spip_articles...") sera
> traduit correctement avec le bon préfixe de table ; en d'autres
> termes, il n'y a rien à faire, c'est entièrement géré par
> spip_query().
>
Tu veux dire que par exemple ces requètes sont gérées automatiquement
avec insertion d'un prefix par SPIP sans rien faire de plus ? :
spip_query('DROP TABLE ma_table');
spip_query("UPDATE $CG_nom_table SET habillage =
".$_POST['changement_habillage_total']." WHERE statut = 7");
A condition que les noms des tables commencent par spip_, oui
Sinon, si tu fais des requettes en dur, parce qu'elle ne sont pas dans
abstract_sql, tu dois au minimum faire quelque chose comme:
spip_query("ALTER TABLE `".$GLOBALS['table_prefix']."_auteurs` ADD
(`flickr_token` TINYTEXT NULL, `flickr_nsid` TINYTEXT NULL);");
Non pas du tout : spip_query("ALTER TABLE spip_articles...") sera
traduit correctement avec le bon préfixe de table ; en d'autres
termes, il n'y a rien à faire, c'est entièrement géré par
spip_query().
en fait, d'après ce que me disait Cedric récemment, il ne faut pas protéger les noms des tables pour que ca marche.
donc "ALTER TABLE spip_auteurs ADD ... "
aura le prefixe remplacé automatiquement,
mais "ALTER TABLE `spip_auteurs` ADD ... "
sera ne s'occupera pas du prefixe.
Perso, j'y voyais l'avantage de pouvoir attaquer simplement les tables d'un spip "principal" en mettant plusieurs spips dans une base, mais avec la gestion des connexions de la SVN, ca n'a plus vraiment de sens.
mais de memoire c'est une histoire de conflits avec les noms de champs commencant pas spip_ qui impose cette bizarrerie.