Bonjour,

L'application est déjà pensée pour permettre une utilisation d'autres SGBD à moindre frais comme vous l'indiquez... Il suffit pour cela par exemple de faire une classe DBOracle ou DBPostgres pour faire l'interfacage et de faire hériter la classe DB de celle ci et non de DBMysql.

Mais les problèmes sont bien autres :
- gestion des installation et mise à jour
- requetage SQL qui est à certains endroits pas forcement compatibles avec les autres SGBD
- ...

Et c'est la toute la problématique qui nous fait patienter pour le moment.

Vous pouvez toujours tentez un portage quelconque mais vous aller vite vous rendre compte des problèmes je pense.
Mais ca serait un test intéressant.

Julien



J'ai fini de cleaner cette partie : plus de free_result qui traine.

Antoine a écrit :
Salut,
J'ai pas fait de patch parce que, bon, effectivement c'est pas très
evident ! Par contre, il me semble qu'avec très peu de modifications
on pourrait arriver à faire qqch qui permettra d'avoir toute fonction
faisant appel à une base dans un seul module ou classe. La plupart du
boulot a déjà été fait.
Je dois avouer que j'ai pas fait beaucoup avec php, et je voulais
comprendre le pourquoi de quelques décisions qui ont été prises. Si
c'est juste "parce qu'on a fait comme ça", tant mieux, mais il se peut
qu'il y a des subtilités qui m'echappent...
Je comprends qu'avec php4 on a ni classes abstraites, ni interfaces.
Donc pour l'instant il faudra probablement les oublier. Mais je ne
vois pas trop l'intérêt d'extendre une classe juste pour affecter
quelques valeurs. Il y a des avantages par rapport à un constructeur
paramétrique (français ?) ? Les classes DB et DBocs pourront dans ce
cas disparaître...
Les appels à la fonction mysql_free_result ont l'air d'être des
bugfixes - l'ajout d'une fonction free_ressources à DBMysql et le
remplacement de ces appels laissent que trois modules qui font appel à
des fonctions mysql - xml.class.php, install.php, et (les) update.php.
J'ai raté qqch ? Pour moi, la modification de ces fichiers pour
utiliser un DBMysql paramétrique est minime.
Ensuite, on pourrait (ou plutôt *je* pourrais ;-)) écrire une fonction
qui retourne l'objet DBMachin qui va bien (par rapport à un fichier
config écrit au moment de l'installation).

L'avantage de cette solution est évidente - elle est rapide et elle
change pratiquement rien dans la logique du programme. Dans ce cas, on
pourrait garder mysql comme la seule base officiellement supportée,
mais il sera facile d'intégrer d'autres bases - et surtout ce sera pas
votre problème ! Il pourrait y avoir un répertoire contrib dans la
distribution... ou pas !
Que est-ce que vous en pensez ? Je le tente, ou ça vous semble pas bon du tout ?
Cheers
Antoine


_______________________________________________
Glpi-dev mailing list
[email protected]
https://mail.gna.org/listinfo/glpi-dev

Reply via email to