PERL est l'acronyme de 'Practical Extraction and Report Language'. Perl est disponible pour tous les systèmes d'exploitation et toutes les plates-formes matérielles au monde. Vous pouvez utiliser Perl sous Windows95/NT, Apple Macintosh iMac, toutes les variétés d'Unix (Solaris, HPUX, AIX, Linux, Irix, SCO etc..), ordinateur central MVS, ordinateur de bureau OS/2, OS/400, Amdahl UTS et beaucoup d'autres. Perl tourne MÊME sur de nombreux matériels et systèmes d'exploitations peu courants/généralement inconnus!! Aussi, ne soyez pas surpris si vous voyez perl tourner sur un système d'exploitation très rarement utilisé.
Cette interface est incluse dans la distribution de PostgreSQL. On la trouve dans le répertoire src/pgsql_perl5.
L'interface de SGBD Perl (Perl Database Interface - DBI) est une interface logicielle d'accès à un SGBD (Application Programming Interface - API) pour le langage PERL. Les spécifications de l'API DBI perl définissent un ensemble de fonctions, de variables et de conventions d'accès à un SGBD cohérent et indépendant du SGBD utilisé. Les informations concernant cette section DBI ont été prises dans la "DBI FAQ" dont l'auteur est Alligator Descartes et sont reproduites ici avec sa permission.
Vous pouvez obtenir DBD-Pg-0.89.tar.gz de l'un des sites indiqués ci-dessous :
CONTRAINTES :
Veuillez envoyer vos commentaires et vos comptes-rendus d'erreurs à
Pensez à inclure la sortie de perl -v, et perl -V, la version de PostgreSQL, la version de DBD-Pg, et la version de DBI dans votre compte-rendu d'erreur.
Pour citer Tim Bunce, l'architecte et l'auteur de DBI :
``DBI est une interface logicielle d'accès aux bases de données (Application Programming Interface -API) pour le langage Perl. Les spécifications DBI API définissent un ensemble de fonctions, de variables et de conventions cohérents d'interfaçage à une base de données indépendant de la base de données utilisée.''
En langage simple, l'interface DBI permet aux utilisateurs d'accéder de manière transparente à de multiples base de données. Ainsi, Si vous vous connectez à une base de données Oracle, Informix, mSQL, Sybase ou n'importe quelle autre, vous n'avez pas besoin de connaître les mécanismes sous-jacents de la couche 3GL. L'API définie par DBI fonctionnera sur tous ces types de bases de données.
On obtient un bénéfice du même ordre en ayant la possibilité de se connecter à deux bases de données de différents fournisseurs à l'aide du même script perl, i.e., je veux lire des données d'une base de données Oracle et les insérer dans une Informix à partir du même programme. La couche logicielle DBI permet de le réaliser simplement et efficacement.
DBperl est le nom ancien des spécifications de l'interface. Il est utilisé maintenant pour désigner les modules perl4 d'interfaçage des bases de données tels que oraperl, isqlperl, ingperl et autres. Ces interfaces n'ont pas d'API standard et ne sont généralement pas supportés.
Voici une liste des modules DBperl, de leur équivalent DBI correspondants et du support d'information. Notez que les auteurs cités ici ne maintiennent généralement pas le module DBI de la base de données. Les adresses E-mail n'ont pas été vérifiées et ne doivent être utilisées que pour les questions concernant les modules perl4 listés ci-dessous. Les questions sur les pilotes DBI doivent être directement adressées aux listes de diffusion des utilisateurs DBI.
Nom du module SGBD requis Auteur DBI
----------- ----------------- ------ ---
Sybperl Sybase Michael Peppler DBD::Sybase
<[email protected]>
Oraperl Oracle 6 & 7 Kevin Stock DBD::Oracle
<[email protected]>
Ingperl Ingres Tim Bunce & DBD::Ingres
Ted Lemon
<[email protected]>
Interperl Interbase Buzz Moschetti DBD::Interbase
<[email protected]>
Uniperl Unify 5.0 Rick Wargo None
<[email protected]>
Pgperl Postgres Igor Metz DBD::Pg
<[email protected]>
Btreeperl NDBM John Conover SDBM?
<[email protected]>
Ctreeperl C-Tree John Conover None
<[email protected]>
Cisamperl Informix C-ISAM Mathias Koerber None
<[email protected]>
Duaperl X.500 Directory Eric Douglas None
User Agent
Cependant, certains modules DBI possèdent des couches logicielles d'émulation. Ainsi
DBD::Oracle est livré avec une couche d'émulation Oraperl, ce qui permet d'exécuter
d'anciens scripts oraperl sans modification. La couche logicielle d'émulation traduit
les appels oraperl API en appels DBI et les exécute.
Voici une table des couches d'émulation :
Module Couche d'émulation État
------ --------------- ------
DBD::Oracle Oraperl Complète
DBD::Informix Isqlperl En cours de développement
DBD::Sybase Sybperl Fonctionnelle? ( Nécessite une
vérification)
DBD::mSQL Msqlperl En version expérimentale avec
DBD::mSQL-0.61
L'émulation Msqlperl est un cas particulier. Msqlperl est un pilote perl5 pour les
bases de données mSQL , mais il ne se conforme pas aux spécifications DBI. On
désapprouve son utilisation en faveur de DBD::mSQL. On peut télé-charger Msqlperl à
partir du site CPAN via :
Il existe quelques sources d'information sur DBI. Spécifications DBI
On trouve deux spécifications disponibles à cette adresse: la nouvelle spécification Draft (édition provisoire) DBI qui est un document en évolution rapide à mesure que l'équipe de développement s'approche d'une version stable de l'interface, et l'ancienne spécification historique DBperl à partir de laquelle l'interface DBI actuelle a évolué.Il faut considérer ce dernier document comme ne présentant qu'un intérêt historique et ne pas l'utiliser en tant que manuel de programmation ou document de référence. Il demeure cependant une source d'informations très utile.
Documentation POD (Plain Old Documentation) Les PODs sont des morceaux de documentation généralement noyés à l'intérieur des programmes perl qui documentent le code "sur place". Ce sont des ressources très utiles pour les programmeurs et les utilisateurs des modules. Les PODs pour DBI et pour les pilotes deviennent monnaie courante et la documentation pour les modules contenant ces PODs peut être lue avec les commandes suivantes.
La Spécification DBI Les PODs pour la spécification DBI peut être lue avec la commande :
perldoc DBI
Oraperl Les utilisateurs de la couche d'émulation fournie avec DBD::Oracle, peuvent s'informer sur la manière de programmer en utilisant l'interface Oraperl en tapant:
perldoc Oraperl
Ce qui permettra d'obtenir une copie à jour de la page de manuel originale écrite par Kevin Stock pour perl4. L'API oraperl y est entièrement listée et décrite.
DBD::mSQL Les utilisateurs du module DBD::mSQL peuvent lire des informations sur quelques fonctions privées et bizarreries de ce pilote en tapant :
perldoc DBD::mSQL
Foire Aux Questions (FAQ) Ce document, la Foire Aux Questions, est aussi disponible en tant que documentation POD! Vous pouvez le lire sur votre propre système en tapant :
perldoc DBI::FAQ
Ceci peut être plus pratique pour ceux qui ne sont pas connectés à l'Internet ou le sont d'une manière peu pratique.
Les POD en général On peut lire des informations sur la manière d'écrire des PODs, ainsi que sur la philosophie des PODs en général en tapant :
perldoc perlpod
Les utilisateurs ayant le module Tk installé seront peut-être intéressés d'apprendre qu'il existe un lecteur de POD basé sur Tk nommé tkpod. Il formate les POD de manière pratique et lisible.
Discussions, Cancans et Observations
Il y a , de temps en temps, une série de discussions de la part de certaines personnes, dans les listes de diffusion sur DBI.
``DBI -- L'interface de SGBD en perl5'' C'est un article écrit par Alligator Descartes et Tim Bunce sur la structure de DBI. Il a été publié dans le numéro 5 de ``The Perl Journal''. Il est extrêmement bon. Allez acheter ce magazine. En fait, achetez les tous. Le site WWW de ``The Perl Journal'' est :
``DBperl'' Cet article, publié dans l'édition de novembre 1996 du ``Dr. Dobbs Journal'' traitait de DBperl.
``The Perl5 Database Interface'' Cette référence est celle d'un livre à écrire par Alligator Descartes publié par O'Reilly et Associés.
Listes de diffusion Il y a trois listes de diffusion pour DBI gérées par Ted Lemon. On peut s'inscrire à toutes et résilier cette inscription à travers le World Wide Web à :
Les listes où les utilisateurs peuvent participer sont:
dbi-announce Cette liste de diffusion est réservée uniquement aux annonces. Si vous n'arrivez pas à utiliser le formulaire sur la page WWW indiquée ci-dessus, inscrivez-vous à cette liste de la manière suivante :
dbi-dev Cette liste de diffusion est à l'usage des développeurs pour discuter des idées et des concepts de l'interface DBI, API et des mécanismes des pilotes. Seulement utiles pour les développeurs et les personnes intéressées. Trafic faible. Si vous n'arrivez pas à utiliser le formulaire sur la page WWW indiquée ci-dessus, inscrivez-vous à cette liste de la manière suivante :
dbi-users Cette liste de diffusion est un lieu de discussion générale utilisée pour les rapports d'erreurs, la discussion sur différents problèmes et des demandes de renseignement d'intérêt général. Si vous n'arrivez pas à utiliser le formulaire sur la page WWW indiquée ci-dessus, inscrivez-vous à cette liste de la manière suivante :
Archives des Listes de Diffusion
Si vous avez un vidage mémoire, essayez le module Devel::CoreStack pour générer une trace de la pile du vidage mémoire. On peut trouver Devel::CoreStack à :
Envoyez un courrier électronique sur la Liste dbi-users contenant la trace de la pile, les versions des modules, la version de perl, les situations de test, la version du système d'exploitation et toutes autres informations pertinentes. Plus vous fournirez d'informations plus vite les développeurs pourront résoudre les problèmes. Si vous ne nous envoyez rien, n'attendez rien en retour.
Les portages de DBI et de DBD::Oracle pour Win32 ports font maintenant partie intégrante de DBI, donc, la récupération d'une version de DBI supérieure à 0.81 doit donner satisfaction. Vous pouvez accéder aux bases de données Microsoft Access et SQL-Server à partir de DBI via ODBC. Une "couche d'émulation" DBI expérimentale est fournie avec DBI-0.79 (et suivants ) pour le module Win32::ODBC. Son nom est DBI::W32ODBC. Vous aurez besoin du module Win32::ODBC.
A l'origine UNIX était bienheureux avec sa "Base de Données" rustique reposant sur des fichiers, nommée système dbm. Avec dbm vous enregistrez les données dans des fichiers et les retrouvez rapidement. Cependant, il souffre de sérieux inconvénients.
Verrouillage des fichiers
Les systèmes dbm ne permettent par un verrouillage particulièrement robuste des fichiers, de même qu'il n'y a pas de possibilité de corriger les problèmes survenants lors d'écritures [ dans la base de données ] simultanées.
Structures de Données Arbitraires
Les systèmes dbm permettent seulement une simple structure de données fixe: paires clé-valeur. Cette valeur peut être un objet complexe, tel qu'une structure [ C ], mais la clé doit être unique. Ce fut une grande limitation dans l'utilité des systèmes dbm.
Cependant, les systèmes dbm continuent d'offrir des fonctions utiles pour les utilisateurs ayant des ensembles de données simples et des ressources limitées, puisqu'ils sont rapides, robustes et extrêmement bien testés. Les modules Perl pour accéder aux systèmes dbm font maintenant partie intégrante de la distribution Perl via le module AnyDBM_File.''
Pour résumer, DBM est une solution parfaitement satisfaisante pour les bases de données essentiellement en lecture seule, ou pour des ensembles de données simples et réduits. Toutefois, pour des ensembles de données plus importants, sans mentionner un verrouillage des transactions robuste, on recommandera aux utilisateurs de préférer DBI.
Si l'on suppose que la fonctionnalité en question n'est pas, en standard, spécifique d'un SGBD, alors la réponse sera non.
DBI représente un API qui doit fonctionner avec la plupart des SGBD, et n'a pas de fonctionnalité spécifique à un SGDB particulier.
Cependant, les auteurs d'un pilote peuvent, s'ils le désirent, ajouter une fonctionnalité spécifique à un SGBD à travers les méthodes func définies dans l'API DBI. Les développeurs de Scripts doivent noter que l'utilisation de cette fonctionnalité au travers de ces méthodes func a de bonnes chances d'en sacrifier la portabilité entre les différents SGBD.
En un mot, oui! DBI est extrêmement utile pour la programmation CGI! En fait, la programmation CGI est une des deux principales utilisation de DBI.
DBI confère aux programmeurs CGI la possibilité d'offrir des base de données WWW à leurs utilisateurs, ce qui donne à ces utilisateurs la possibilité d'utiliser de grandes quantités de données bien organisées. DBI donne aussi la possibilité , si un site reçoit un trafic trop important pour les performances du serveur, d'améliorer ce serveur de base de données de façon transparente, sans modifier les scripts CGI.
Le serveur httpd Apache maintient un ensemble de processus fils httpd pour servir les requêtes clients.
En utilisant le module mod_perl Apache de Doug MacEachern, l'interpréteur perl est inclus dans le processus fils httpd. Les modules CGI, DBI, et vos autres modules favoris peuvent être chargés au lancement de chaque processus fils. Ces modules ne seront pas rechargés à moins d'être modifiés sur disque.
Pour de plus amples informations sur Apache, consultez le site WWW du Projet Apache à :
En utilisant le module Apache::DBI de Edmund Mergl, les connexions à la base de données sont enregistrées dans une table avec chacun des processus httpd fils. Si votre application utilise une base de données simple utilisateur, cette connexion peut être lancée avec chaque processus fils. Actuellement, les connexions à la base de données ne peuvent pas être partagées entre processus httpd fils. Apache::DBI peut être télé-chargé de CPAN via :
Fondamentalement, il y a une bonne chance que cela provienne du fait que l'utilisateur à partir duquel vous avez lancé la ligne de commande a un ensemble de variables d'environnement correctement configuré, ce sont, dans le cas de DBD::Oracle, des variables telles que $ORACLE_HOME, $ORACLE_SID ou TWO_TASK. Le processus httpd s'exécute habituellement sous un utilisateur id ne correspondant pas à un utilisateur, ce qui implique qu'il n'y a pas d'environnement configuré. Tous scripts essayant de s'exécuter dans ces circonstances échoueront. Pour résoudre ce problème, initialisez l'environnement de votre base de données dans un bloc BEGIN ( ) en tête de votre script. Ceci devrait résoudre votre problème. De même, vous devriez regarder votre fichier registre d'erreurs pour y trouver des indices, ainsi que les guides "Idiot's Guide To Solving Perl / CGI Problems" et "Perl CGIProgramming FAQ" pour avoir des informations complémentaires. Il est peu probable que ce problème concerne DBI. Lisez ces DEUX documents très soigneusement !
A la date de ce document, non. perl ne permet pas l'exécution en parallèle. Cependant, l'exécution en parallèle doit faire partie de la distribution perl de base à compter de la version 5.005, ce qui sous-entend que le support de l'exécution en parallèle pour DBI devrait suivre rapidement. Pour quelques exemples de code OCI pour Oracle ayant des instructions SELECT avec exécution en parallèle, voir :
En supposant que vous avez créé une procédure enregistrée à l'intérieur de la base de données cible, e.g., une base de données Oracle, vous pouvez utiliser $ dbh-> do pour exécuter immédiatement cette procédure. Par exemple,
$ dbh-> do( "BEGIN someProcedure END" );
N'oubliez pas d'effectuer un test d'erreur, strict!
$sth = $dbh->prepare( "BEGIN foo(:1, :2, :3); END;" );
$sth->bind_param(1, $a);
$sth->bind_param_inout(2, \$path, 2000);
$sth->bind_param_inout(3, \$success, 2000);
$sth->execute;
La création et la suppression de bases de données sont des concepts qui sont beaucoup trop abstraits pour être supportés par DBI. Par exemple, Oracle ne supporte pas le concept de détruire une base de données du tout ! Ainsi, dans Oracle, le serveur de base de données est essentiellement la base de données elle-même alors que dans mSQL, le processus serveur s'exécute tranquillement sans aucune base de données créée. C'est un problème trop hétérogène pour s'y attaquer. Quelques pilotes, cependant, supportent la création et la suppression de bases de données à travers des méthodes func privées. Il vous faut regarder dans la documentation des pilotes que vous utilisez pour vérifier s'ils supportent de tels mécanismes.
Les valeurs NULL dans DBI sont traitées comme la valeur undef. Des NULLs peuvent être insérés dans les bases de données en tant que NULL, par exemple :
$rv =
$dbh->do( "INSERT INTO table VALUES( NULL )" );
mais lors d'une interrogation, les NULLs devront être testés comme des undef.
C'est une norme pour tous les pilotes.
Une méthode func est définie à l'intérieur de DBI comme étant un point d'entrée pour une fonctionnalité d'une base de données spécifique, eg, la possibilité de créer ou supprimer des bases de données. L'invocation de ces méthodes spécifiques aux pilotes est simple. Par exemple, pour invoquer une méthode createDatabase qui n'a qu'un seul argument, on écrira :
$rv = $dbh->func( 'argument', 'createDatabase' );
Les développeurs de logiciels doivent cependant noter que ces méthodes func
ne sont pas portables entre SGBD.
L'interface aux SGBD Perl5 est un logiciel LIBRE. IL EST DISTRIBUE SANS GARANTIE D'AUCUNE SORTE. Cependant, quelques organisations fournissent soit une assistance technique soit des programmes de formation pour DBI.
PERL CLINIC : La société "Perl Clinic" peut offrir des contrats d'assistance payants pour Perl, DBI, DBD::Oracle et Oraperl. Cette assistance est fournie par la compagnie où travaille Tim Bunce, auteur de DBI. Pour de plus amples informations concernant leurs services, consultez :