ca sera pas trop difficilement gérable, pour autant que GLPI utilise du code SQL un peu plus standard que le bouzin de MySQL. en SQL92, une transaction commence toujours par un begin, et se termine par un commit. Le plus dur dans l'histoire sera simplement d'avoir la même "interface" pour chaque fonction de chaque dbms, et pour cela, je propose déja qu'on se base sur le nom des fonctions de la classe DBmysql (glpi/glpi/common/classe.php), en modifiant les paramètres la ou il faut (insert_id($table) - PostGre ne peut sortir le dernier identifiant que pour une table, pas pour toute la base de donnée, ce qui est assez logique au passage).
Cependant, je suis tout à fait d'accord pour la réunion sur IRC hein ;-) nicodache On Wed, 30 Mar 2005 22:19:21 +0200 (CEST), DOMBRE Julien <[EMAIL PROTECTED]> wrote: > > Dans la foulée, je commence à porter le code pour Oracle et DB2 en > > utilisant > > une logique MVC, avec un backend de données abstrait, le code, et la > > couche > > présentation en utilisant les templates. Pour la maintenance et les > > évolutions, ça me semble plus pratique. > > Si plusieurs personnes commencent a bosser de manière séparée pour porter > GLPI sur tel ou tel SGBD qui lui semble meilleur, ca va pas être gérable > sincèrement... > > On va se retrouver avec 10 versions de GLPI différentes et pour nous cela > sera ingérable. > > Pour faire les choses de manière efficace, le plus simple est déjà > d'attendre la sortie de la 0.5. > Ensuite on plannifiera une petite réunion commune sur IRC avec tous les > gens intéressés par l'utilisation d'autres SGBD pour se mettre d'accord > déjà si ca a un réel intérét et surtout sur comment le faire... > Une fois que les choses seront eclairsies là vous pourrez faire du boulot > rentable pour GLPI ;) > > Julien > > _______________________________________________ > Glpi-dev mailing list > Glpi-dev@gna.org > https://mail.gna.org/listinfo/glpi-dev >
