2010-04-27 6 views
3

Nous avons une application où la base de données contient une grande partie de la logique métier dans les déclencheurs, avec une mise à jour qui déclenche ensuite des déclencheurs sur plusieurs autres tables. Je veux refactoriser le désordre et je voulais commencer par extraire les procédures des déclencheurs, mais je ne trouve aucun outil fiable pour le faire. L'utilisation de "procédure d'extraction" dans SQL Developer et Toad n'a pas réussi à gérer correctement: new et: old les variables de trigger.Refactoring des déclencheurs PL/SQL - Procédures d'extraction

Si vous avez eu un problème similaire avec les déclencheurs, avez-vous trouvé un moyen de contourner le problème?

EDIT: Idéalement, seules les colonnes référencées par code extrait seraient envoyés comme dans/sur les paramètres, comme:

Exemple de code original à extraire de la détente:

..... 
    if :new.col1 = some_var then 
    :new.col1 := :old.col1 
    end if 
    ..... 

deviendrait :

procedure proc(in old_col1 varchar2, in out new_col1 varchar2, some_var varchar2) is 
    begin 
    if new_col1 = some_var then 
     new_col1 := old_col1 
    end if; 
    end; 
    ...... 
    proc(:old.col1,:new.col1, some_var); 
+1

Idéalement, comment voudriez-vous que la fonction "extraire la procédure" gère les: anciennes et: nouvelles variables? –

+0

J'ai ajouté la réponse à la question originale. – Juraj

Répondre

0

Ceci n'est pas exactement la réponse. Je n'ai pas assez de réputation pour éditer la question originale, évidemment. Le problème est que ce n'est pas un «refactoring» comme on pense habituellement. Même lorsque vous créez un tas de procédures à partir de déclencheurs, vous devez créer un cadre approprié pour les exécuter afin d'obtenir les fonctionnalités d'origine. Je soupçonne que ce sera aussi un défi. Comme proposition de solution, j'irais avec un script python, basé sur la machine d'état (voir http://www.ibm.com/developerworks/library/l-python-state.html par exemple). Si vous mettez une définition stricte de ce qui doit être traduit et comment, il sera facile à mettre en œuvre.

+0

Je ne suis pas sûr d'avoir compris ce que vous voulez dire et comment voulez-vous éditer la question? Je sais que l'extraction des procédures n'est pas la fin en soi. Mais il y a une grande différence entre avoir des blocs de code énormes, dupliqués et non maintenus dans les déclencheurs et avoir le même code divisé logiquement dans les procédures (bien qu'ils seront toujours appelés à partir des mêmes déclencheurs). En ce qui concerne le script python, je préfère aller avec quelque chose qui a été testé et testé spécifiquement pour PL/SQL. Il y a déjà une telle fonctionnalité, elle ne tient pas compte des: nouvelles et: anciennes variables, semble-t-il. – Juraj

+0

Oh, et je peux plus facilement écrire des tests unitaires pour les procédures. Le test des déclencheurs est PITA. – Juraj

+0

Désolé, mon point était que je ne peux pas obtenir comment ajouter le commentaire à la question au lieu de répondre. Et pour reformuler mon point: 1. Pour créer des procédures sur des déclencheurs n'est pas exactement "refactoring" sauf si vous allez remplacer des corps de déclencheurs avec quelque chose comme: créer ou remplacer le déclencheur "MY_TABLE_INS" avant d'insérer sur my_table pour chaque ligne begin my_ins_trigger_proc (: nouveau.field,: ancien.field); fin; Il n'est pas clair à partir de la réponse originale ce que vous allez faire avec les procédures "extraites" 2.La fonctionnalité dont vous avez besoin est juste une transformation de texte, et c'est le domaine de Python, perl etc. – dbaranov

1

Il semble que vous souhaitiez effectuer des transformations sur une source PL/SQL. Pour ce faire de manière fiable, vous avez besoin d'un outil qui peut analyser PL/SQL à un type de structure de données du compilateur, faire correspondre les patterns à cette structure et effectuer des modifications, puis régénérer le code PL/SQL modifié.

Le DMS Software Reengineering Toolkit est un outil de ce type. Il est paramétré par le langage de programmation en cours de traduction; Il dispose d'interfaces frontales standard pour de nombreuses langues, notamment C, C++, C#, Java, COBOL et ... PL/SQL.