bonjour
mon FAI travaille avec un serveur postgreSql. je ne peux donc ouvrir une galerie photo avec phpwebgallery. connaissez-vous un logiciel identique permettant de créer une galerie photo sur l'espace perso alloué par mon FAI ?
merçi
Hors ligne
Pour avoir testé gallery il y a fort longtemps, c'était déja une vaste "usine à gaz". Il est complet mais parfois un peu trop à mon gout. Ca a peut être un peu évolué avec la v2.
Il pose parfois problème chez certains hébergeurs (problème de droits, de type de variables PHP).
Je ne connais pas bien PostgreSQL, mais ça reste un SGBD basé sur SQL, ça devrait être facile de faire un support pour lui non ?
Hors ligne
volcom a écrit:
Pour avoir testé gallery il y a fort longtemps, c'était déja une vaste "usine à gaz". Il est complet mais parfois un peu trop à mon gout. Ca a peut être un peu évolué avec la v2.
Il pose parfois problème chez certains hébergeurs (problème de droits, de type de variables PHP).
Gallery serait-il aux galleries d'images en ligne le phpBB des forums ? Si c'est le cas, je suis content que PhpWebGallery soit plus proche de punBB :-) Je m'égare...
volcom a écrit:
Je ne connais pas bien PostgreSQL, mais ça reste un SGBD basé sur SQL, ça devrait être facile de faire un support pour lui non ?
Non, car PhpWebGallery n'utilise pas que des requêtes standard, il y a des petits trucs spécifiques à MySQL, et s'en passer poserait des problèmes de performances.
Le support de postgreSQL avait été énoncé il y a 2 ans : Possibilité De Choisir Une Autre Bdd Que Mysql puis, début 2004, sur la section privée du forum, nous en discutions avec Gweltas. Je copies ici le contenu du topic :
z0rglub a écrit:
Bon alors voilà le sujet : doit-on ajouter une couche d'abstraction pour la gestion de plusieurs gestionnaire de base de données ? (DBMS : Database Management System)
Je lance le "débat" et disant que oui, ce serait intéressant, voyons maintenant comment ça pourrait être possible :
· 1. en n'utilisant que des requêtes qui marchent partout -> pas top parce qu'on utilise pas les spécificités de chaque DBMS, on se cale sur le plus basique et on risque d'avoir des soucis de perfs
· 2. en ayant une abstraction forte, on centralise toutes les requêtes dans un seule fichier (ou groupe de fichier) qui serait en fonction du DBMS, en redéfinissant des fonctions génériques du type "get_categories", ou "get_images( $category_id )"... -> beaucoup plus long à faire je pense, mais optimal pour chaque gestionnaire de base de données.
Gweltas a écrit:
L'intérêt d'une couche d'abstraction c'est que ca permettrait en plus d'avoir une version de debug permanente avec le debug puisqu'il sera bien plus facile de tracer le nombre de requetes par exemple.
L'inconvénient majeur de cette couche, c'est que si elle n'est pas utilisée, elle coûte en performances.
On se trouve donc devant un choix :
- avoir un support multi DBMS (pas si long que cela à mettre en place) qui coûte en performances
- rester en mysql tout bête, mais avec une moins bonne évolutivité.
J'avoue que je serai tenté pour le mettre en branche 1.5 avec possibilité de le ramener en 1.4 si jamais on a le temps.
z0rglub a écrit:
On se trouve donc devant un choix :
- avoir un support multi DBMS (pas si long que cela à mettre en place) qui coûte en performances
- rester en mysql tout bête, mais avec une moins bonne évolutivité.oui, je suis bien d'accord que ça va coûter en perfs, surtout si on utilise la solution 1 de mon premier post (à la manière d'un phpBB dont je pense tu t'inspires pas mal :-)
Pour l'évolulitivité, là je te suis pas du tout. On ne donnera pas le choix aux utilisateurs de leur DBMS, mais ça ne gêne pas du tout pour l'évolutivité (au contraire même). Moins tu supportes de DBMS, mieux tu exploites les possibilités des DBMS supportés
(à mon boulot, notre grosse application est une sorte de gros programme greffé sur Oracle, ça porte le méga inconvénient d'être lié à une société commerciale propriétaire, si elle coule, nous aussi, mais on peut vraiment fignoler notre schéma de base de données)J'avoue que je serai tenté pour le mettre en branche 1.5 avec possibilité de le ramener en 1.4 si jamais on a le temps.
Ouais, je suis d'accord pour qu'on se laisse le temps d'y réfléchir :-) Le support de PostGreSQL m'intéresse pas mal ! (mais là comme ça, pour moi, la solution 2, c'est mieux)
Avec 1 an 1/2 d'expérience supplémentaire, je pense que c'est plutôt le support de SQL Lite qui sera bénéfique pour PhpWebGallery, et pas PostgreSQL. A réfléchir.
PS : elmer, tu avais déjà créé le topic php webgallery compatible avec PgSQL
Hors ligne
Bonjour,
Je me permet de réouvrir ce topic concernant les bases postgresql suite à la découverte de cette bibliothèque : http://adodb.sourceforge.net/
Je ne sait ce que cela peut donner dans les performances que vous attendez de PhpWebgallery mais cela vaut peut etre le coup d'essayer.
P.S.: je suis dans le cas d'elmer autant dire si je suis aussi interresé ....
Hors ligne
darkpeanut a écrit:
[... AdoDB ...] Je ne sait ce que cela peut donner dans les performances que vous attendez de PhpWebgallery mais cela vaut peut etre le coup d'essayer.
J'ai de très mauvais échos en terme de performances sur adoDB. Maintenant, je n'ai pas testé, donc c'est juste une rumeur.
Voir aussi le récent bug 511 qui remonte le sujet.
Hors ligne