🌍
Français
"Sil il se trompe dans la requête ça peut avoir un impact sur la totalité de la table, donc tout les mods."
Bien vu...
Il est à mon avis bien utile d'en discuter.
8-)
PS: Je n'ai pas contrôlé comment le pb est approché par d'autres (wordpress, doctlear, etc). Si quelqu'un en a une bonne idée... 8-)
Pour la requête je suis d'accord (enfin j'ai rien à redire) mais pour le nom de la table je le suis moins. Ca va vite devenir le bazar dans #_images_extensions si chaque mod qui veut modifier un champ de la table extension et créé sa propre ligne. Et autre problème que je viens de trouver. Lors d'une mise à jour d'un mod, l'auteur modifie la valeur de son champ. Sil il se trompe dans la requête ça peut avoir un impact sur la totalité de la table, donc tout les mods.
Ce qui donnerait selon ma vision des choses...
Les mod/plugins feraient donc:
CREATE TABLE IF NOT EXISTS `phpwebgallery_images_extensions` ( `id` mediumint(8) unsigned NOT NULL auto_increment, PRIMARY KEY (`id`), ) TYPE=MyISAM; ALTER TABLE `phpwebgallery_images_extensions` ADD COLUMN `plug_int_name` CHAR(20) NULL;
et/ou
CREATE TABLE IF NOT EXISTS `phpwebgallery_images_extensions` ( `id` mediumint(8) unsigned NOT NULL auto_increment, PRIMARY KEY (`id`), ) TYPE=MyISAM; ALTER TABLE `phpwebgallery_images_extensions` ADD COLUMN `plug_blob_name` BLOB NULL;
La table n'existerait pas en standard.
Elle aurait 2 ou 3 colonnes ou plus suivant les mod/plugins installés.
8-)
PS: J'ai mis plug_int_name en char(20) mais pourrait être en INT(5) (complétement absurde je sais).
8-)
Salut, jusqu'a présent je suis favorable pour la création d'une table spécifique au mod dans le cas ou celui-ci ajout des champs et non modifie des champs dans PhpWebGallery. Au contraire pour ce qui concerne la modification du shéma d'origine c'est plus délicat. Certe il vaut mieux créer un nouveau champ plutôt que modifier un existant mais où le mettre ? Je suis d'avis de le mettre dans une table différente propre au mod. Un exemple :
Je décide de faire un mod MOD_INT qui modifie le champs name dans #_images, je le transforme en INT(5) (complétement absurde je sais). Demain j'install un le mod MOD_BLOB qui lui aussi modifie ce champs et le passe en BLOB (encore plus absurde). Comment gérer le conflit ?
Maintenant le même exemple avec des tables différentes :
Je décide de faire un mod qui ajoute une table qui aura cette forme :
mod_int{mod_int_id_image (INT(5)), name (CHAR(20))}Demain j'install MOD_BLOB qui ajoute une table qui aura cette forme :
mod_blob{mod_blob_id_image (INT(5)), name (BLOB))}Reste plus qu'a ce mettre d'accord sur une convention de nommage de champs venant de mod et trouver un moyen pour avoir une intégration facile dans les requêtes de PhpWebGallery.
Pour le nommage des champs qui prenne place de ceux de PhpWebGallery, je propose d'utiliser de rajouter le initial du mod voir le nom complet en rajoutant le type (plugin ou mod). Ce qui pourrait donner pour l'exemple ci-dessus.
mod_int{mod_int_id_image (INT(5)), mod_int_name (CHAR(20))}
mod_blob{mod_blob_id_image (INT(5)), mod_blob_name (BLOB))}Dans le cas de plugins
pg_int{pg_int_id_image (INT(5)), pg_int_name (CHAR(20))}
pg_blob{pg_blob_id_image (INT(5)), pg_blob_name (BLOB))}Au contraire pour l'intégration dans les requêtes de PhpWebGallery ça me dépasse pour le moment.
Il ne s'agit de prévoir mais de conseiller uniquement.
Le conseil ne s'adresse pas à un développeur de MOD mais à plusieurs.
Extensions google_maps, verso, media_integrator, et autres...
Ne pas créer plusieurs #images_extensions mais une seule.
Ne pas créer de colonnes ayant un nom trop générique.
8-)
Non, je pense que prévoir une table #sites_extensions est inutile. Mon conseil s'adresse à un développeur de MOD, le développeur sait ce qu'il fait normalement. Conceptuellement, c'est mieux d'avoir une table séparée, mais ce n'est pas du tout nécessaire. On se prendrait un peu trop la tête si on devait prévoir tous les types d'extension possible.
Je me permet juste de poser une question en fait... Le problème ne se pose-t'il pas pour toutes les tables ? Certes, moi mes besoins ne couvrent que celle des sites à présent, mais on peut imaginer une extension qui veut rajouter des infos dans la table images (ou autre finalement).
Faudrait-il dans ce cas créer pour chaque table de PHPWG une table équivalente du type (nom_de_base)_extension ? Je ne connais pas assez bien PHPWG, ni toutes les extensions qui sont proposées, mais j'ai l'impression (qui peut être tout à fait fausse) que seul un petit nombre des modules a vraiment besoin d'étendre les données présentes dans la BD.
Mon humble avis sur l'affaire est qu'il faudrait créer un vrai système de modules (vous m'avez parlé de la version 1.7, je n'ai pas beaucoup regardé, et à vrai dire trouver les modifications à partir des logs cvs pourrait s'avérer assez copieux). Je cite l'exemple du CMS Drupal que j'utilise en parallèle avec PHPWG qui a un système de modules que je trouve exemplaire. Ceci dit, le modèle employé dans ce projet ne peut pas être adapté à mon avis à PHPWG, du fait de la nature tout à fait divergente des deux applications (CMS et gallerie ont des buts et obstacles bien différents).
Mais qui sait, vous pourrez peut-être y trouver une source d'inspiration...
Suite de : Modification de la structure de la BD pour un module
J'ai souhaité plutôt que que continuer sur le post en question, discuter sur le fond avant de penser au Wiki.
Rappel:
z0rglub a écrit:
Mon conseil : pour faire les choses vraiment proprement, rien de tel qu'une table séparée qui serait lié à #sites par jointure. La table spécifique au module doit au moins contenir un champ site_id (norme de nommage dans PhpWebGallery).
A quoi...
VDigital a écrit:
Je suis d'accord avec toi, z0rglub.
Une nuance, tout de même, c'est que tout le monde n'a pas la connaissance nécessaire pour concevoir une évolution de la structure de cette façon.
et
rub a écrit:
A mon avis, il faut plus qu'on donne un petit exemple dans le WIKI de comment créer une table pour jointure et un exemple de requête avec jointure.
Bien, certes il faut documenter le moyen de modifier la stucture.
Mais si demain, j'ai une, puis deux, puis trois tables liées à #sites ou toute autre table...
La performance ne sera plus au rendez-vous.
Je préconise de tenter la création de la table #sites_extensions (unique pour toutes les extensions).
1 - La table doit rester unique, au début elle devrait être dans toute extension qu'avec l'id de la table associée.
CREATE TABLE IF NOT EXISTS `phpwebgallery_sites_extensions` ....
2 - Puis les autres colonnes spécifiques à l'extension devraient être ajoutée par ALTER
3 - Mais surtout ces colonnes doivent être un peu normalisées... Quid de deux colonnes "comment" ou "size" pour des extensions donc des besoins différents... ?
Suis-je en dehors de la plaque ???
8-)