Rollback de transaction: Scénarios
Quand vous mappez les données dans une base de données, vous pouvez rencontrer diverses erreurs liées à la base de données (par ex., le compte de base de données ne peut pas avoir assez de privilèges pour réaliser une action de base de données spécifique). Pour prévenir de telles erreurs d’annulation de l’exécution du mappage, vous pouvez configurer des paramètres de restauration de la transaction, qui vous permettrons de restaurer les changements. Vous pouvez activer une restauration de transaction au niveau du composant de base de données au niveau de l’action de table, et au niveau de la procédure stockée.
Ce chapitre décrit quelques-uns des scénarios possibles des rollbacks de transaction. Tous les scénarios de ce chapitre caractérisent un fichier source XML appelé Authors.xml et une base de données cible appelée BookCatalog.sqlite (mappage ci-dessous). Les tables Authors et Books ont une relation de clé étrangère. La table Author est le parent de la table Books.
Dans tous les scénarios, les mêmes actions de table de base de données ont été configurées :
•La combinaison des actions Update If et Insert Rest dans la table Authors. La condition Update If est définie dans la colonne Author.
•La combinaison des actions Update If et Insert Rest dans la table Books. La condition Update If est définie dans la colonne Titre.
De plus, le traçage a été activé au niveau du composant (défini à Toujours), dans la table Authors (Utiliser les paramètres de composant), et la table Books (Utiliser les paramètres de composant). Les paramètres de rollback de transaction rollback varieront dépendant du scénario.
Présentation sommaire des scénarios
Les scénarios décrits dans ce chapitre sont décrits ci-dessous :
•Scénario 1 : Si un enregistrement Author est erroné, il sera restauré avec tous ses enregistrements enfant ; si seul un enregistrement Book est erroné, alors seul cet enregistrement sera renvoyé.
•Scénario 2 : Si un enregistrement Author est erroné, il sera retourné avec tous ses enrgistrements enfant.
•Scénario 3 : Si un enregistrement Book est erroné, seul cet enregistrement sera restauré.
•Scénario 4 : Si un enregistrement Book ne peut pas être inséré, ses enregistrements parent seront restaurés (de manière semblable au Scénario 2).
•Scénario 5 : S’il existe une erreur associée à la base de données, tous les changements effectués dans la base de données seront restaurés.
Scénario 1 : Rollback Author et Book actuels
Dans le premier scénario, nous permettons la gestion de transaction au niveau de l’action de table : L’option Restaurer transaction actuelle et continuer est définie dans les deux tables de la base de données. La combinaison de ces paramètres signifient que (i) s’il y a un enregistrement Author défectueux, ni cet enregistrement, ni ses enregistrements enfant Book ne seront insérés dans la base de données, puis le traitement du prochain enregistrement démarrera ; (ii) s’il existe un enregistrement Book défectueux mais que son enregistrement parent Author est valide, uniquement l’enregistrement Book défectueux sera annulé, et le traitement du prochain enregistrement se démarrer.
Authors.xml
Le fichier Authors.xml contient des informations sur les auteurs et leurs livres. Un des enregistrements Author manque d’information sur le pays de l’auteur. Le fichier source a également un enregistrement Book qui ne contient pas d’information sur l’éditeur. :
BookCatalog.sqlite
Nous avons défini une contrainte NOT NULL dans la colonne Country dans la table Authors et la colonne Publisher dans la table Books. Mapper les valeurs null à ces colonnes causera une erreur.
Sortie
Après avoir exécuté le script SQL dans le volet Sortie, nous obtenons le dialogue suivant :
Le dialogue Exception de transaction de base de données nous informe sur l’erreur liée à la base de données et la raison de cette erreur. Dans cet exemple, une valeur null n’a pas pu être insérée dans la colonne Country de la table Authors (rectangle rouge ci-dessus). Cette boîte de dialogue permet aussi de choisir la prochaine action. Par défaut, l’action configurée dans le dialogue Actions de Table de base de données est sélectionnée. Il est possible d’appliquer le même paramètre à toutes les erreurs suivantes ou d’annuler la transaction défectueuse et d’arrêter.
Après avoir confirmé la sélection, nous recevons une autre notification sur une autre erreur qui est apparue dans la table Books (capture d’écran ci-dessous). Cette erreur est apparue car le mappage a tenté d’insérer l’information absente Publisher d’un de nos enregistrements Book dans le champ Publisher de la table Books. Puisque l’erreur est apparue dans la table enfant, il est possible de restaurer la transaction actuelle (Restaurer cette transaction et arrêter/continuer) ou les changements de la transaction supérieure (Restaurer le haut et arrêter/continuer). La transaction du niveau supérieur dans ce contexte signifie l’enregistrement parent (Author) de l’enregistrement enfant erroné (Book).
S’il existe plusieurs niveaux dans la hiérarchie, une restauration aura lieu pour chaque niveau jusqu’à ce que la restauration atteigne le niveau le plus élevé auquel la transaction a été activée. Selon vos besoins, vous pouvez choisir de continuer ou arrêter l’exécution de mappage. L’option Restaurer le haut et continuer/arrêter est disponible uniquement lorsqu’il existe des transactions imbriquées. Pour plus d’information sur la restauration des transactions du haut, voir le Scénario 4 ci-dessous.
Dans cet exemple, nous laissons l’option de restauration de la transaction affichée dans la capture d’écran ci-dessus inchangés. Après la fin du traitement, de tous les enregistrements, nous pouvons voir les instructions SQL générées dans le volet Sortie, le rapport de trace sous le format XML, et les données qui sont désormais disponibles dans la base de données.
Instructions SQL générées
Un extrait du script SQL généré est illustré ci-dessous. L’opération insert échouée a été restaurée dans SAVEPOINT. La commande SAVEPOINT représente un point de transaction auquel la transaction sera restaurée. La commande SAVEPOINT permet de défaire les changements effectués après SAVEPOINT et de restaurer la transaction à l’état au moment du SAVEPOINT.
Rapport de trace
Un extrait du rapport de trace est fourni ci-dessous : Le rapport de trace affiche les champs et leurs valeurs qui ont été tracées (par ex., <Price>8.6</Price>), fournit des informations sur les actions réalisées (par ex., insert) et l’erreur (voir l’élément trace:error).
<Books>
<trace:values>
<Title>Cockroaches</Title>
<AuthorID>41</AuthorID>
<ISBN>0099590328</ISBN>
<Publisher xsi:nil="true"/>
<NumPages>464</NumPages>
<Year>2016</Year>
<Genre>Crime & Mystery</Genre>
<Price>8.6</Price>
</ trace:values>
<trace:actions>
<trace:update rows-affected="0"/>
<trace:insert>
<trace:error code="19" state="1299">contrainte NOT NULL échouée : Books.Publisher</trace:error>
</ trace:insert>
</ trace:actions>
</Books>
Mettre à jour les données dans la BD
Pour voir quelles données sont disponibles dans la base de données, vous pouvez utiliser le volet Requête BD. L’extrait de la table Books ci-dessous affiche que plusieurs enregistrements ont été insérés avec succès. Puisqu’insérer un des livres de Jo Nesbo a échoué (rapport de trace ci-dessus), uniquement deux de ces trois livres ont été mappés (The Bat et The Redbreast).
Autres scénarios possibles
D’autres scénarios possibles sont décrits ci-dessous.
Scénario 2 : Restaurer Author actuel et tous les livres de l’auteur
Dans ce scénario, la transaction de restauration actuelle et l’option continuer est définie uniquement dans la table Authors. Au sein de cette configuration, chaque enregistrement Author et les enregistrements correspondants Book sont perçus comme opération atomique. S’il existe un enregistrement Author erroné ou au moins un des livres d’auteur qui est erroné, cet enregistrement de l’auteur et ses enregistrements enfant associés seront restaurés. Puis, le traitement continue avec le prochain enregistrement Author.
Scénario 3 : Restaurer uniquement Book actuel
Dans ce scénario, la transaction de restauration actuelle et l’option continuer est définie uniquement dans la table Livres. S’il existe un enregistrement erroné Book, seul l’enregistrement Book sera restauré, et le traitement continuera. Si vous définissez la transaction de restauration du niveau supérieur et l’option continuer dans la table Books et aucune autre option de gestion de la transaction au niveau parent, ce ne sera que l’enregistrement Book erroné qui sera restauré. Dans ce cas, il n’y a pas de différence entre une restauration de la transaction du niveau supérieur et actuel, car il n’existe qu’un niveau de transaction et pas d’imbrication de transaction.
Scénario 4 : Restauration de Author si Book ne peut pas être inséré
Dans ce scénario, l’action de transaction pour la table Authors est définie pour Restaurer la transaction actuelle et continuer, et l’action de transaction pour la table Books est Restaurer la transaction du niveau supérieur et poursuivre. Avec cette configuration, si insérer un enregistrement enfant échoue, l’opération de restauration sera effectuée pour chaque niveau de la hiérarchie, jusqu’au niveau le plus élevé auquel la gestion de la transaction a été activée. Par exemple, nous voulons insérer un nouvel enregistrement Author (Jo Nesbo) et ses trois enregistrements enfant. Dans un des enregistrements Book (The Cockroaches), il n’existe aucune information sur l’éditeur. Puisque la table Books n’a pas de contrainte NOT NULL dans la colonne Publisher, mapper la valeur null dans ce champ causera une erreur. Dans ce scénario, lorsqu’une erreur apparaît, l’enregistrement Book erroné (The Cockroaches) sera restauré ensemble avec les deux autres enregistrements Book et l’enregistrement parent. Puis, le traitement continuera avec le prochain enregistrement Author.
La combinaison des options de gestion de transaction décrite dans ce scénario est particulièrement pertinente pour les structures complexes et imbriquées (par ex., une table parent avec deux ou plusieurs tables enfant)
Scénario 5 : Restaurer toutes les transactions de BD et continuer
Dans ce scénario, la transaction de restauration actuelle et l’option continuer sont définies uniquement dans la table Livres. Ce paramètre peut être particulièrement utile quand vous avez un mappage en chaîne (par ex., XML-DB-JSON). S’il existe une erreur associée à la base de données, tous les changements réalisés dans les composants de base de données seront restaurés et le traitement continuera avec le composant JSON.