Simplifier les mises à jour avec .NET Provider

Les exemples cités dans l’article sont accessibles via le Club Abonnés.

L’IBM i Access for Windows .NET Provider est à la disposition des programmeurs. Malgré quelques changements de nom au fil des ans, le provider continue à améliorer le fonctionnement et le rendement de votre base de données IBM i. L’une des nouvelles fonctions les plus séduisantes est Row Change Timestamp, une option qui permet à une application .NET d’effectuer des mises à jour plus rapidement qu’avant.

Si vous avez déjà utilisé conjointement le data adapter class (iDB2DataAdapter) de .NET provider et le command builder (iDB2CommandBuilder), vous savez combien il est facile de générer des instructions INSERT, UPDATE, et DELETE pour mettre à jour vos tables DB2 for i. Vous n’écrivez qu’un petit fragment de code, et le command builder fait le plus dur : générer les instructions de mise à jour. Ce qui vous libère du temps pour des tâches plus nobles.

Bien que la génération de commande automatique du provider traite admirablement les mises à jour de la base de données, la syntaxe SQL générée peut être longue et encombrante et doit traiter beaucoup de données avant qu’une mise à jour ne s’exécute avec succès. À partir de la release 6.1, une nouvelle fonction du command builder rend encore plus efficaces les mises à jour de la base de données. Je vous montre ici comment profiter de ce mécanisme plutôt que de répéter les méthodes éprouvées du passé.

Modèle de simultanéité optimiste

Dans un monde parfait, les mises à jour des tables ne seraient faites que par une seule application à la fois, et aucune application ne reviendrait jamais sur les changements faits par une autre. La réalité est moins idyllique. Et c’est dans cette optique que la classe CommandBuilder d’un ADO.NET provider génère des commandes destinées à mettre à jour une table, par une méthode baptisée simultanéité optimiste.

Dans ce contexte, une application ne peut mettre à jour une ligne que si le contenu de celle-ci à la source des données est resté inchangé depuis sa première lecture par l’application. Ce modèle de mise à jour suppose, de manière optimiste, que la plupart des mises à jour ne seront pas en conflit avec les changements effectués par d’autres applications. Ce postulat présente l’avantage de ne pas nécessiter de verrous sur les tables ou les lignes. Quant à l’inconvénient, vous le devinez : une mise à jour peut échouer avec une violation de simultanéité si une autre application a changé les données depuis leur première lecture.

Avant, c’était comment ?

Pour apprécier pleinement les mérites de la nouvelle option iDB2CommandBuilder update, voyons comment s’effectuaient les mises à jour optimistes dans les versions 5.4 et antérieures de l’IBM i Access for Windows .NET provider.

Tout d’abord, pour utiliser le command builder, il fallait inclure une clé unique ou primaire dans la table spécifiée dans l’instruction SELECT de l’adaptateur de données. Cela identifiait précisément la ligne à mettre à jour ou à supprimer. Ensuite, le provider effectuait la mise à jour optimiste de la manière suivante : il comparait la valeur actuelle de chaque colonne à la valeur originale pour voir si elle avait changé depuis sa première lecture. De plus, les champs “nullables” avaient besoin d’une clause WHERE supplémentaire, parce que pour vérifier des valeurs nulles dans une base de données il faut avoir une syntaxe IS NULL spéciale. L’exemple de la figure 1 montre une instruction UPDATE typique pour une table contenant six champs plus une clé primaire.

Vous pouvez voir que la clause WHERE générée compare le contenu de tous les champs de la table, un à un. Dans notre petit exemple, il y a peu de champs à comparer, mais supposez que votre table en contienne bien davantage, ou que le contenu de chacun soit bien plus grand. Dans de tels cas, les comparaisons champ par champ seraient bien trop longues lors de l’exécution de l’instruction UPDATE.

Nouvelles possibilités

Quand le .NET Framework 2.0 est arrivé, il introduisait une nouvelle propriété de command builder appelée ConflictOption. Avec cette propriété, votre application peut choisir comment le command builder doit générer ses instructions UPDATE et DELETE. Avec l’option ConflictOption.CompareRowVersion, il n’est plus nécessaire de comparer chaque champ de la table à sa valeur originale. Au lieu de cela, nous utilisons le champ Row Change Timestamp et un identificateur d’enregistrement unique dans la clause WHERE, à des fins de comparaison.

On le voit, CompareRowVersion simplifie l’instruction UPDATE de la figure 2, qui est générée pour une table contenant un Row Change Timestamp. Que la table ITEMS contienne six champs ou 600, la clause WHERE de l’instruction UPDATE est presque identique.

Pour profiter de ce nouveau mode de mise à jour, vous devez remplir plusieurs conditions :

•    L’instruction SELECT de votre adaptateur de données ne doit référencer qu’une seule table.
•    La table référencée dans l’instruction SELECT doit contenir un champ Row Change Timestamp.
•    Votre client IBM i Access for Windows et le serveur IBM i doivent être en version 6.1 ou ultérieure.
•    La propriété ConflictOption du command builder doit être réglée sur CompareRowVersion (c’est la valeur par défaut).

Si votre table est dépourvue d’un champ Row Change Timestamp, ou si votre serveur IBM i est antérieur à la version 6.1, le comportement revient à ConflictOption.CompareAllSearchableValues, c’est-à-dire le même que dans les releases précédentes.

Comparer les deux modèles de mises à jour

L’exemple de programme de la figure 3 montre bien les différences entre les deux modèles de mise à jour. En utilisant Visual Studio 2008 ou 2005, créez une application C# Console, ajoutez une référence à l’IBM.Data.DB2.iSeries .NET provider, et changez les variables datasource et lib pour qu’elles correspondent à votre environnement. Puis exécutez le programme. Vous verrez la différence entre les instructions UPDATE générées quand la table n’a pas de Row Change Timestamp et quand la table est modifiée pour contenir un champ Row Change Timestamp.

En utilisant un Row Change Timestamp avec CompareRowVersion,  vous pouvez bien sûr réduire la taille et la complexité de l’instruction UPDATE de votre command builder. Mais, en modifiant légèrement l’exemple de programme, vous pouvez également opérer la même réduction dans l’instruction DELETE générée.

Toujours plus de gains de performances

Une autre amélioration de DB2 for i version 6.1 permet au .NET provider de bénéficier tranquillement d’une fonction qui peut réduire le temps de traitement nécessaire pour effectuer des mises à jour. Dans nos exemples UPDATE, vous pouvez voir que l’iDB2CommandBuilder émet une instruction SET qui inclut toutes les colonnes susceptibles d’être mises à jour dans la table. Mais supposons une table avec beaucoup de colonnes dont vous ne voulez changer qu’une seule. Dans ce cas, ce serait du gaspillage que de mettre à jour toutes les colonnes.

Pour remédier à cette situation, le .NET provider détecte quand une colonne faisant l’objet d’une mise à jour n’a pas changé de valeur depuis sa première lecture. Dans ce cas, le provider ne traite pas les colonnes affectées ; au lieu de cela, il définit la valeur d’indicateur non assigné dans le flux de données quand l’instruction UPDATE va vers le i. Le serveur détecte que la colonne n’a pas besoin de mise à jour et saute le traitement la concernant. Le non- traitement des colonnes inchangées améliore nettement les performances, surtout quand le jeu de résultats contient de grandes quantités de données qui restent inchangées pendant la mise à jour.

Et le plus beau est que, pour profiter du traitement UPDATE amélioré avec des valeurs d’indicateur non assigné, votre application n’a rien à faire ! Tout cela est effectué par le handshaking interne entre le .NET provider et la base de données. Le paramètre qui affecte cela est la propriété SetAllValues de l’iDB2CommandBuilder, et la propriété valide ce support par défaut lorsqu’on est connecté à un serveur IBM i version 6.1  ou ultérieure.

Avancer et simplifier !

Vous venez de découvrir les économies potentielles que vous pouvez réaliser dans le code de mise à jour de votre application. J’espère que vous essaierez les nouvelles fonctions de .NET provider. Et que vous constaterez qu’il est possible de réduire le temps et les données nécessaires pour mettre à jour votre base de données !