Bonjour,
Je viens de terminer un premier rapide petit tour du code, et voici
les horreurs propres à MySQL que j'ai pu trouver (ceci aidera
peut-être certaines personnes qui sont également en train de porter
GLPI vers d'autres DBMS, et indiquera aux développeurs de
l'application comment coder le plus standard possible avec un DBMS qui
en est loin ;-)) :
- lors de l'authentification de l'utilisateur (ex : glpi), vous
utilisez la fonction password de mysql (SELECT password('$password')
AS password). Ce qui est comique la dedans, c'est qu'il m'a été
signalé (par guiguidoc) que cette fonction est utilisée en interne par
MySQL pour vérifier l'identification d'un utilisateur, et qu'elle ne
devait pas etre utilisée pour un projet de développement. De plus,
cette fonction (de hachage) n'est en rien comparable à ce qu'o peut
trouver dans la nature, à savoir qu'il ne s'agit pas de MD5, de SHA,
ou encore de DES, ce qui signifie que tant avec PHP qu'avec une base
de donnée, il ne sera possible de reproduire le comportement de cette
fonction. Il faut donc absolument se passer de cette fonction (ce qui
pose un autre problème; l'utilité de garder le password haché dans la
base de donnée, ainsi que la somme MD5 du hash. Pourquoi ne pas garder
simplement le MD5 du password clair ? bien que l'algorithme MD5 ait
été "cassé" récemment, il faut encore un pc plutot puissant pour en
venir à bout, ce qui fait que transférer un MD5SUM de password par le
réseau est probablement aussi - si pas plus sécurisé que le password
de mysql, celui-ci utilisant un hash de 45 bits. Faudra qu'on en
discute, car j'avoue que ca obligera à réécrire toute la partie
authentification user)
- comme déja expliqué, le mot user est un mot réservé dans SQL92
- de même que le mot ID dans certaines bases de données
- la fonction mysql_insert_id qui renvoie le dernier indice
auto-incrémenté sur toute la base de donnée ne fonctionne pas comme
ceci sous postgre. en effet, ce dernier requiert une table, car il
donne le dernier indice d'une table, et non d'une base de donnée
complète. Ce qui a plusieurs avantages, entre autre la plus petite
probabilité de tomber sur une fausse valeur due à 2 inserts trop
raprochés. (de plus sans transaction (au sens vrai du terme) dans
mysql). Cependant, il n'est pas compliqué de changer ceci dans le
code, la table pour laquelle nous souhaitons récupérer le dernier
indice étant souvent nommée explicitement 5 lignes plus haut dans le
code ;-)
- mysql contient une fonction list_table, qui renvoie une liste des
tables d'une base de donnée. Cependant, cette fonction est bien sur
propre à MySQL, et après avoir fouillé dans PostGre, il semble qu'il
soit quasi impossible de refaire cette fonction, à moins de récupérer
du même coup les colonnes propres au dbms (OID etc...). Il faudrait
donc s'en passer (cette fonction est utilisé dans une des fonctions
appelée par computer/index.php, au hazard show_computer_list()).
- il vous arrive d'insérer un nouvel enregistrement dans la base de
donnée comme ceci :
nous avons une table qui contient : ID not null auto_increment, toto
varchar(255)
et vous faites un INSERT INTO table VALUES (NULL, "tagada plop");
le seul problème relevé ici est que si mysql mange ca sans broncher,
un DBMS correct (et pas que PGSQL) refusera d'insérer NULL dans un
champ not null auto incrémenté. Il faut donc changer ce code en INSERT
INTO table (toto) VALUES ("tagada plop");
- support de LIMIT et OFFSET :
mysql utilise une syntaxe particulière pour les limites et les
déplacements, à savoir qu'il peut soit faire : "SELECT
tout_plein_de_trucs LIMIT {offset},{limit};", soit faire "SELECT
tout_plein_de_trucs LIMIT {limit} OFFSET {offset}.
La bonne nouvelle dans l'histoire est que la 2eme version semble bien
plus standard, et est supportée par PGSQL (ainsi que surement d'autres
dbms, mais j'ai pas été voir).
- dernier grief pour l'instant, le SHOW COLUMNS FROM table, qui
n'existe pas avec autre chose que MySQL, et qui est utilisé dans le
code pour recevoir les noms des colonnes d'une table sur laquelle on
va faire/compte faire un select...
Voila donc une liste non-exhaustive des problèmes que les personnes
qui comptent porter GLPI de mysql vers un autre DBMS rencontreront
probablement
On Mar 31, 2005 10:32 AM, nicodache <[EMAIL PROTECTED]> wrote:
> Avez-vous déja une idée sur la "librairie d'interfacage" la plus
> efficace et complète pour la base de donnée ?
> pearDB, ADO, ou encore méta(chépluquoi) ?
>
> nicodache
>
> On Thu, 31 Mar 2005 05:39:43 +0200, DJ Anubis <[EMAIL PROTECTED]> wrote:
> >
> > A moins d'aimer les usines à gaz avec des batches pour tenter de rendre
> > interopérables des applications. Glpi étant une gestion de parc
> > informatique,
> > il s'agit d'un produit destiné à des entreprises ou groupes possédant un
> > parc
> > suffisant pour nécessiter une telle gestion.
> > Dans ce cas, forcer l'utilisation d'un SGBD particulier risque de provoquer
> > le
> > rejet pur et simple du soft par les administrateurs SGBD.
> >
> > Il existe une règle simple qui permet d'éviter les mots réservés dans les
> > noms
> > de colonnes, préfixer tous les champs des tables. Par exemple, une table
> > contacts voit ses champs préfixés par ctc_.
> >
> > Attention également au champ ID. C'est un mot réservé avec Ovrimos, comme
> > OID
> > avec PostgreSQL. En ayant examiné une soixantaine de SGBD, ous en sommes
> > venus à "recid" comme champ primary key, celui-ci n'étant utilisé par
> > personne.
> >
> > Les plaisirs de la portabilité commencent ;-)
> >
> > --
> > JCR
> > aka DJ Anubis
> > LAB Project Initiator and coordinator
> >
>
