> Tech > Favoriser la réutiliation du code SQL avec des Macros

Favoriser la réutiliation du code SQL avec des Macros

Tech - Par Paul Conte - Publié le 24 juin 2010
email

Le SPL (Stored Procedure Language) de SQL est excellent pour écrire des procédures stockées (SP, stored procedures), des fonctions définies par l’utilisateur (UDF, user-defined functions) et triggers. SPL offre de nombreuses fonctions que l’on trouve dans les langages évolués (HLL) polyvalents tels que RPG et Cobol. Et l’étroite intégration de SPL, du DLL (data definition language) et du DML (data manipulation language) de SQL simplifie beaucoup de programmes d’accès à DB2 et à d’autres bases de données. Les SP, les UDF et les déclencheurs sont très utiles pour la plupart des genres d’applications et sont essentiels pour quiconque utilise Java, .NET et autres langages et outils de type Web.Cependant, après une utilisation plus approfondie de SPL, vous constaterez qu’il n’a presque pas de fonctions liées à la réutilisation du code : pas de fonctions de programmation orientée objet, pas de sous-procédures, pas même une simple facilité include. Ce manque de moyens de réutilisation oblige les développeurs à utiliser des techniques copier/coller qui produisent de nombreuses occurrences des mêmes fragments de code dans un portfolio de SP, d’UDF et de déclencheurs. L’un des exemples les plus accablants à mes yeux est l’obligation de répliquer le code de traitement des exceptions dans pratiquement tout membre source (ou fichier IFS). La manière dont SPL aborde le traitement des exceptions est incommode, et pour créer des programmes robustes avec SPL, il faut une astucieuse manipulation du code. Le fait d’inclure une copie physique du code de traitement des exceptions standard dans chaque SP, UDF et déclencheur, alourdit sensiblement l’aspect maintenance de tout projet.

Mon insatisfaction face à cet aspect de la programmation SPL m’a conduit à rechercher des moyens de réutilisation du code. En tant que consultant d’un projet SPL, j’ai aidé un client confronté aux mêmes problèmes à créer un générateur de code polyvalent. A dire vrai, cette solution était peu coûteuse et couvrait les modes de réutilisation de code que le client rencontrait le plus fréquemment. Mais un générateur de code personnalisé ne constitue pas une solution généralisée et il faut un travail supplémentaire pour écrire et maintenir le générateur de code et le code d’application. J’ai donc récemment réexaminé le problème et trouvé un puissant outil standard qui répond à la plupart de mes besoins de réutilisation de code SPL.

L’outil en question est le macro préprocesseur Unix appelé m4. D’abord destiné à Unix, cet utilitaire existe maintenant pour Windows également (voir l’encadré : Pour en savoir plus, pour plus d’informations sur m4). J’utilise m4 conjointement à WDSc sur mon système Windows XP pour produire le code SPL que je peux ensuite exécuter et déboguer avec iSeries Navigator.

Un préprocesseur lit un ou plusieurs fichiers de code source en entrée et produit un ou plusieurs fichiers source en sortie. Généralement, certains des fichiers de sortie sont ensuite compilés. Pour le développement SPL, vous pouvez utiliser m4 pour produire un fichier de sortie avec une instruction SQL Create Procedure, Create Function, ou Create Trigger. L’instruction respective contient le code de mise en oeuvre SPL pour le SP, l’UDF, ou le déclencheur.

Un macro préprocesseur a quatre fonctions principales :

• Une facilité include qui vous permet d’incorporer des morceaux de code source (et définitions de macros) à partir d’un ou plusieurs fichiers, en plus dans le fichier d’entrée principal
• des définitions d’expansions de macros paramétrées
• le traitement conditionnel
• des opérations élémentaires d’arithmétique, de logique et de chaîne, pour manipuler du texte.

Je décris ici brièvement comment m4 utilise chacune de ces fonctions, et je jette un coup d’oeil rapide à un exemple SPL.

Téléchargez cette ressource

Sécuriser votre système d’impression

Sécuriser votre système d’impression

Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.

Tech - Par Paul Conte - Publié le 24 juin 2010