Bonjour,
j'ai besoin de modifier un peu la structure de la BD pour le module que je développe. Plus précisement j'ai besoin d'ajouter (au moins) un champ dans la table des sites distants.
Je voulais savoir si ça allait causer des soucis avec PHPWG par la suite ? A priori, le cas qui pourrait être ennuyeux est une insertion (update aussi, mais je ne suis pas sûr) sans énumération des champs. Par exemple:
INSERT INTO <tables des sites distants> VALUES (3, 'http://le.site.distant/');
Si je rajoute un champ supplémentaire, cette requête échoue normalement. Quelqu'un sait si des requêtes de ce style se trouvent dans PHPWG ?
Je peux chercher (et à la limite je le ferai pour me faire une idée rapide), mais je profite également de ce post pour savoir si c'est particulièrement recommandé d'éviter ce genre de méthodes. A priori, mes modifications ne toucheront pas aux données déjà présentes, donc on peut facilement "défaire" les modifs à la structure.
Merci d'avance
Hors ligne
Tant que j'y suis, est-ce que le champ "path" dans la table d'images pour les fichiers étant sur un site distant est très important (mis à part pour afficher l'image bien évidemment). Ce que je veux savoir c'est s'il est utilisé pour autre chose que juste l'affichage (par exemple, s'il est utilisé pour avoir des informations sur les répertoires qui contiennent l'image, etc.).
Merci
Hors ligne
acp a écrit:
INSERT INTO <tables des sites distants> VALUES (3, 'http://le.site.distant/');
Si je rajoute un champ supplémentaire, cette requête échoue normalement.
Si tu ajoutes une colonne, ça sera avec une default value, donc pas de pb. Non?
Hors ligne
Le champ path est important pour plein des choses (c'est pour ca qu'il est la). Et il n'y a aucune garantie que on ne fera pas une utilisation supplementaire demain.
Peux-tu decrire ce que tu cherches faire exactement ?
Hors ligne
acp a écrit:
Tant que j'y suis, est-ce que le champ "path" dans la table d'images pour les fichiers étant sur un site distant est très important (mis à part pour afficher l'image bien évidemment). Ce que je veux savoir c'est s'il est utilisé pour autre chose que juste l'affichage (par exemple, s'il est utilisé pour avoir des informations sur les répertoires qui contiennent l'image, etc.).
Merci
Le champ path est bien entendu utilisé pour l'affichage mais aussi pour les opérations de maintenance qui reconstituent justement le path de chaque image.
Il vaut mieux éviter toute modification.
Je ne comprends pas ce que tu voudrais en faire.
8-)
Hors ligne
C'est en fait pour la gestion de site distants dans le module secureImages. Je croyais au début que je pouvais juste changer le champ "path" du fichier listing.xml (je remplace par http://hop.com/getRemoteFile.php?id=X) et que hop ça allait être bon. Mais la synchro ne marchait plus (en effet dirname sur http://hop.com/getRemoteFile.php?id=X et http://hop.com/categorie/souscategorie/image1.jpg, c'est pas pareil).
A la limite, je pensais ajouter un champ id_remote à la table d'images, puis un champ du style path_to_remote_getFile dans la table des sites distants (enfin des sites en général finalement, puisque ./galleries en fait partie). Ça devrait résoudre mes problèmes. Mais j'aurai préféré ne pas toucher à la BD.
Hors ligne
Je pense que modifier le path n'est pas une solution viable a terme (on l'utilise pour pas mal des choses).
De toute maniere dans la version 1.7 il y aura quelques modifications dans pwg pour faciliter l'integration des modules (secure images compris).
Hors ligne
acp a écrit:
Hmmm intéressant ça. Un petit avant-goût de ce qui est prévu, enfin comment vous comptez faciliter l'intégration des modules ?
Indice https://mail.gna.org/listinfo/phpwebgallery-cvs
et http://svn.gna.org/viewcvs/phpwebgallery/
Si tu descends la version trunc, tu auras un aperçu dans admin, il ya un nouveau menu mais je ne dirais pas plus.
Hors ligne
acp a écrit:
Hmmm intéressant ça. Un petit avant-goût de ce qui est prévu, enfin comment vous comptez faciliter l'intégration des modules ?
C'est un peu premature car toujours en cours de dev et pas encore finalise
Hors ligne
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).
Concernant #images.path, c'est un champ "calculé". C'est à dire qu'à tout moment, on peut supprimer sa valeur et la recalculer par lecture dans #sites.galleries_url, #categories.dir et #categories.uppercat_id et #images.file. Donc, il ne faut pas y toucher, c'est une espèce de cache.
Hors ligne
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.
Il faudrait qu'on "discute" sur les règles à respecter, ne crois-tu pas?
8-)
Hors ligne
Cette façon de s'y prendre m'avait traversé l'esprit, mais pour une raison qui m'échappe encore, j'ai quelques choses contre les 'JOIN'. Ceci dit, l'avantage est que du coup, revenir en arrière est encore plus simple et plus rassurant pour l'utilisateur final.
Hors ligne
VDigital a écrit:
J
Il faudrait qu'on "discute" sur les règles à respecter, ne crois-tu pas?
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.
Hors ligne