[SPIP Zone] CFG + nouvelle colonne dans les tables + DUMP = ?

Archives Zone
1

Bonjour,

Fil suggérait que CFG ne s'appuie pas, pour les storages des préférences sur des auteurs ou sur des rubriques, sur le champs 'extra' des tables, plutot réservé à autre chose.

Il proposait d'utiliser 'prefs' ou un champs 'cfg' tout simplement.

Du coup, j'ai modifié CFG (ce n'est pas commité car il y a un hic) pour que l'on puisse sauvegarder dans n'importe quelle colonne d'une table, par défaut la colonne 'cfg' (pour le nouveau storage 'tablepack') ou la colonne 'extra' pour le storage 'extrapack' pour compatibilité.

Actuellement, avec ce que j'ai codé :

Lorsque l'on tente d'écrire un contenu sur une colonne, si celle-ci n'existe pas, CFG la crée à la volée (sql_alter()).
On peut alors écrire, lire, modifier exactement comme CFG faisait avec 'extrapack'.

Le hic, c'est que la colonne n'est pas déclarée a SPIP et si l'on fait un DUMP, la colonne est bien sauvegardée...

Mais la restauration ne restaure pas les valeurs (alors qu'elle le fait pour 'prefs' ou 'extra').

Du coup, je ne sais pas trop comment proposer une nouvelle colonne, pour que spip l'intègre dans ses restaurations. La solution la plus barbare, ça serait de :
1) ne pas créer automatiquement les colonnes par cfg si elles n'existent pas
2) mais créer la colonne 'cfg' pour un certain nombre de tables SPIP à l'installation (auteurs, articles, rubriques) de CFG et les déclarer évidemment.

Quelqu'un aurait il des idées/suggestions ?

MM.

2

Matthieu Marcillaud a écrit :

Bonjour,

Fil suggérait que CFG ne s'appuie pas, pour les storages des préférences sur des auteurs ou sur des rubriques, sur le champs 'extra' des tables, plutot réservé à autre chose.

Il proposait d'utiliser 'prefs' ou un champs 'cfg' tout simplement.

Du coup, j'ai modifié CFG (ce n'est pas commité car il y a un hic) pour que l'on puisse sauvegarder dans n'importe quelle colonne d'une table, par défaut la colonne 'cfg' (pour le nouveau storage 'tablepack') ou la colonne 'extra' pour le storage 'extrapack' pour compatibilité.

Actuellement, avec ce que j'ai codé :

Lorsque l'on tente d'écrire un contenu sur une colonne, si celle-ci n'existe pas, CFG la crée à la volée (sql_alter()).
On peut alors écrire, lire, modifier exactement comme CFG faisait avec 'extrapack'.

Le hic, c'est que la colonne n'est pas déclarée a SPIP et si l'on fait un DUMP, la colonne est bien sauvegardée...

Mais la restauration ne restaure pas les valeurs (alors qu'elle le fait pour 'prefs' ou 'extra').

Du coup, je ne sais pas trop comment proposer une nouvelle colonne, pour que spip l'intègre dans ses restaurations. La solution la plus barbare, ça serait de :
1) ne pas créer automatiquement les colonnes par cfg si elles n'existent pas
2) mais créer la colonne 'cfg' pour un certain nombre de tables SPIP à l'installation (auteurs, articles, rubriques) de CFG et les déclarer évidemment.

Quelqu'un aurait il des idées/suggestions ?

MM.

Bonjour, je ne sais pas si tu es toujours à la recherche d'une solution à ton problème. Cependant j'ai peut être une idée à te proposer qui pourrais être considérer comme 3ème solution :). Voila nous savons pour la plus part d'entre nous que la déclaration des tables et des colonnes personnalisés sont effectuée dans le fichier mes_fonctions du plugin (ou plus généralement dans un fichier dans /base qui est lui même inclus dans mes_fonctions). Tu conviendras qu'en général on effectue une déclaration statique des tables et des colonnes. Cependant je pense que rien ne nous empêche de faire une déclaration dynamique. C'est à dire que tu crée une table dédiée à stocker par exemple le nom des tables auquels cfg à créer une colonne. Puis à travers, par exemple, une fonction tu régénères la déclaration de ces colonnes dans mes_fonctions en tirant les informations de la table précédente. Théoriquement, ça devrait marcher. Personnellement je l'ai testé avec juste des tables, et le DUMP voyait bien ces tables déclarer dynamiquement. Malheureusement je n’ai pas poussé mon expérimentation plus loin. J'espère que m'a proposition pourra t'aider.

Cordialement,

GUIOUBLY William

3

william a écrit :

Bonjour, je ne sais pas si tu es toujours à la recherche d'une solution à ton problème.

si !

Tu conviendras qu'en général on effectue une déclaration statique des tables et des colonnes. Cependant je pense que rien ne nous empêche de faire une déclaration dynamique.

C'est vrai

C'est à dire

que tu crée une table dédiée à stocker par exemple le nom des tables auquels cfg à créer une colonne. Puis à travers, par exemple, une fonction tu régénères la déclaration de ces colonnes dans mes_fonctions en tirant les informations de la table précédente.

Hum... oui. Ca peut se tenir... (appelons la spip_cfg ici)
Mais sur un site neuf, il suffit que cette table soit déclarée pour qu'elle se restaure... cependant, il ne connaitra pas encore, lors d'une restauration, les champs ajoutés à restaurer, vu qu'ils sont déclarés dans la table spip_cfg dont les valeurs vont être ajoutées avec le dump.

MM.

4

Matthieu Marcillaud a écrit :

william a écrit :

Bonjour, je ne sais pas si tu es toujours à la recherche d'une solution à ton problème.

si !

Tu conviendras qu'en général on effectue une déclaration statique des tables et des colonnes. Cependant je pense que rien ne nous empêche de faire une déclaration dynamique.

C'est vrai

C'est à dire

que tu crée une table dédiée à stocker par exemple le nom des tables auquels cfg à créer une colonne. Puis à travers, par exemple, une fonction tu régénères la déclaration de ces colonnes dans mes_fonctions en tirant les informations de la table précédente.

Hum... oui. Ca peut se tenir... (appelons la spip_cfg ici)
Mais sur un site neuf, il suffit que cette table soit déclarée pour qu'elle se restaure... cependant, il ne connaitra pas encore, lors d'une restauration, les champs ajoutés à restaurer, vu qu'ils sont déclarés dans la table spip_cfg dont les valeurs vont être ajoutées avec le dump.

MM.

Ouias, effectivement, j'avais oublié un peu cette aspect :s. C'est problématique. Faudrait il que SPIP prévoit un moyen alternatif pour stoker la déclaration des tables et des colonnes. Bon je vais continuer à réfléchir sur ton problème je pense bien qu'il dois avoir une solution pour le résoudre. (peut surcharger le fichier qui créer les DUMP ?)

GUIOUBLY William

5

* Matthieu Marcillaud tapuscrivait, le 20/12/2007 21:44:

william a écrit :

Bonjour, je ne sais pas si tu es toujours à la recherche d'une solution à ton problème.

si !

Tu conviendras qu'en général on effectue une déclaration statique des tables et des colonnes. Cependant je pense que rien ne nous empêche de faire une déclaration dynamique.

C'est vrai

C'est à dire

que tu crée une table dédiée à stocker par exemple le nom des tables auquels cfg à créer une colonne. Puis à travers, par exemple, une fonction tu régénères la déclaration de ces colonnes dans mes_fonctions en tirant les informations de la table précédente.

Hum... oui. Ca peut se tenir... (appelons la spip_cfg ici)
Mais sur un site neuf, il suffit que cette table soit déclarée pour qu'elle se restaure... cependant, il ne connaitra pas encore, lors d'une restauration, les champs ajoutés à restaurer, vu qu'ils sont déclarés dans la table spip_cfg dont les valeurs vont être ajoutées avec le dump.

Et si tu incorporais au mécanisme de restauration de SPIP de créer les champs qui n'existent pas.
Du coup, il faudrait aussi incorporer au mécanisme de sauvegarde de donner le type des champs (type, valeur par défaut, index, foreign key...).

--
RealET