SnowConvert AI - Rapport des unités de code de niveau supérieur¶
Qu’est-ce qu’une unité de code de niveau supérieur ?¶
Une unité de code, comme son nom l’indique, est l’élément exécutable le plus atomique et le plus autonome. Dans la plupart des cas, il s’agit d’instructions, mais aussi de fichiers de scripts, car ceux-ci sont exécutés en tant qu’élément unique.
Certaines unités de code peuvent être imbriquées dans d’autres unités de code. Lorsqu’il n’y a pas d’autre unité de code au-dessus dans une hiérarchie d’unités, on parle d’unité de code de niveau supérieur.
Qu’est-ce qu’une unité de code hors champ d’application ?¶
Les unités de code de niveau supérieur hors champ d’application sont des unités de code qui sont hors du champ d’application de la conversion de SnowConvert AI. Pour cette raison, ces unités de code ne sont pas prises en compte lors du calcul du taux de conversion. Aucune de ces unités de code n’aura un taux de conversion (il apparaîtra comme N/A).
Si le code d’entrée ne comprend que des unités de code hors champ d’application, le taux de conversion des lignes de code de l’ensemble de la migration sera de 0 %.
La commande CREATE TRIGGER suivante est considérée comme une unité de code hors champ d’application.
CREATE OR REPLACE TRIGGER my_trigger
AFTER
UPDATE
ON my_table
FOR EACH ROW
BEGIN
NULL;
END;
Exemples d’unités de code de niveau supérieur¶
Dans la section suivante, nous pouvons voir quelques exemples d’unités de code de niveau supérieur.
Requêtes¶
Dans l’exemple suivant, il s’agit d’une instruction SELECT unique. Cette instruction est une unité de code unique de niveau supérieur.
SELECT * FROM table1;
Dans cet exemple, nous avons une instruction SELECT imbriquée dans une autre instruction SELECT. La requête entière compte pour une unité de code unique de niveau supérieur.
SELECT * FROM (SELECT * FROM table1);
Objets¶
Les objets créés à l’aide d’un DDL comptent pour une unité de code unique de niveau supérieur, même s’ils contiennent d’autres unités de code.
L’instruction suivante crée une vue avec une requête. Dans ce cas, CREATE VIEW compte pour une unité de code unique de niveau supérieur.
CREATE VIEW view1 AS SELECT * FROM table1;
L’instruction CREATE PROCEDURE compte pour une unité de code unique de niveau supérieur, même si elle contient plusieurs instructions.
CREATE PROCEDURE procedure1
AS
BEGIN
DELETE FROM table1;
END;
Commandes¶
Les commandes indépendantes d’un fichier SQL sont considérées comme des unités de code de niveau supérieur.
Une instruction COMMIT compte pour une unité de code unique de niveau supérieur.
COMMIT;
Corps des paquets dans Oracle¶
Un paquet peut définir plusieurs éléments à l’intérieur de son corps. Le corps du paquet est considéré comme l’unité de code de niveau supérieur car ces éléments ne peuvent être créés individuellement sans créer le corps entier du paquet. Les éléments ou unités de code à l’intérieur du corps d’un paquet ne sont pas comptabilisés comme unités de code de niveau supérieur.
Le code suivant sera signalé comme une unité de code CREATE PACKAGE BODY unique.
CREATE PACKAGE package_body1 IS
FUNCTION function1
RETURN VARCHAR
IS
BEGIN
RETURN 'HELLO'';
END;
END;
Fichiers de script Teradata¶
Les fichiers de script Teradata tels que BTEQ ou TPUMP sont exécutés en tant qu’unités de code autonomes. De ce fait, le fichier entier est considéré comme une unité de code unique de niveau supérieur. Les autres unités de code possibles à l’intérieur de ces fichiers ne sont pas comptabilisées comme unités de code de niveau supérieur.
Le fichier de script BTEQ suivant sera signalé comme une unité de code unique BTEQ de niveau supérieur.
.LOGON e/fml,notebook
.COMPILE FILE = example.spl;
COMMIT;
CALL samplesp1 (8888, pAmount);
.LOGOFF
Lots Transact SQL avec GOTO¶
Chaque instruction de lot Transact SQL peut être exécutée indépendamment. Dans la plupart des cas, chacune de ces instructions est considérée comme une unité de code de niveau supérieur. Toutefois, lorsqu’un lot contient une instruction GOTO sur une étiquette à l’intérieur du même lot, les instructions du lot ne peuvent pas être exécutées indépendamment sans que l’on s’assure qu’elles fonctionnent correctement. Pour cette raison, les instructions qui font partie d’un lot avec une instruction GOTO ne compteront pas pour unités de code de niveau supérieur, mais seulement le lot.
L’exemple de code suivant sera signalé comme une unité de code GOTO/LABEL unique :
DECLARE @Counter int;
SET @Counter = 1;
WHILE @Counter < 10
BEGIN
SELECT @Counter
SET @Counter = @Counter + 1
IF @Counter = 4 GOTO Branch_One
IF @Counter = 5 GOTO Branch_Two
END
Branch_One:
SELECT 'Jumping To Branch One.'
GOTO Branch_Three;
Branch_Two:
SELECT 'Jumping To Branch Two.'
Branch_Three:
SELECT 'Jumping To Branch Three.';
GO
Comment la méthodologie d’unité de code est-elle représentée dans d’autres rapports ?¶
La méthodologie d’unité de code est également représentée dans d’autres rapports. Cette section explique comment ces valeurs sont affichées ou sont liées à d’autres rapports.
Rapport sur les problèmes¶
Chaque ligne du rapport sur les problèmes contient des informations sur l’unité de code concernée par le problème. Les colonnes relatives aux unités de code sont les suivantes :
Base de données de l’unité de code : Il s’agit de la base de données de l’unité de code de niveau supérieur où le problème a été détecté. Elle ne s’applique qu’aux unités de code qui sont des objets.
Schéma de l’unité de code : Il s’agit du schéma de l’unité de code de niveau supérieur où le problème a été détecté. Elle ne s’applique qu’aux unités de code qui sont des objets.
Paquet de l’unité de code : Il s’agit du paquet de l’unité de code de niveau supérieur où le problème a été détecté. Elle ne s’applique qu’aux unités de code qui sont des objets.
Nom de l’unité de code : Il s’agit du nom de l’unité de code de niveau supérieur où le problème a été détecté. Il ne s’applique qu’aux unités de code nommées, comme les objets. Ce nom n’est pas qualifié par une base de données, un schéma ou un paquet.
ID de l’unité de code : Il s’agit de l’ID de l’unité de code de niveau supérieur où le problème a été détecté. Ce nom est qualifié et un numéro est ajouté pour les unités de code dont le nom est répété.
Unité de code : Il s’agit du type de l’unité de code de niveau supérieur où le problème a été détecté.
Taille de l’unité de code : Il s’agit de la taille de l’unité de code de niveau supérieur où le problème a été détecté.
Rapport sur les références d’objet et rapport sur les objets manquants¶
Chaque ligne du rapport sur les références d’objets contient des informations sur l’unité de code de niveau supérieur qui faisait référence à un autre élément. Ces éléments référencés peuvent ne pas être de niveau supérieur, de sorte que ces autres valeurs peuvent ne pas être incluses dans le rapport sur les unités de code de niveau supérieur.
De même que le rapport sur les références d’objets, le rapport sur les objets manquants contient des informations sur l’unité de code de niveau supérieur qui faisait référence à un élément introuvable dans le code.
Unité de code de l’appelant : Il s’agit du type de l’unité de code de niveau supérieur qui fait référence à un autre élément.
Base de données de l’unité de code de l’appelant : Il s’agit de la base de données de l’unité de code de niveau supérieur qui fait référence à un autre élément.
Schéma de l’unité de code de l’appelant : Il s’agit du schéma de l’unité de code de niveau supérieur qui fait référence à un autre élément.
Nom de l’unité de code de l’appelant : Il s’agit du nom de l’unité de code de niveau supérieur qui fait référence à un autre élément.
Nom complet de l’unité de code de l’appelant : Il s’agit du nom complet de l’unité de code de niveau supérieur qui fait référence à un autre élément.
Informations contenues dans le rapport sur les unités de code de niveau supérieur¶
Colonne |
Description |
|---|---|
Clé de partition |
L’identificateur unique de la conversion. |
Type de fichier |
Le type du fichier dans lequel se trouve l’unité de code. (SQL, BTEQ, etc…) |
Catégorie |
La classe ou le type plus large auquel appartient chaque unité de code. |
Unité de code |
Le type d’unité de code auquel cet élément appartient. |
Base de données source |
La base de données où se trouve l’unité de code source. |
Schéma de la source |
Le schéma où se trouve l’unité de code source. |
Nom de la source |
Le nom d’origine de l’unité de code source tel qu’il apparaît dans le système source. |
ID d’unité de code |
L’identificateur unique de l’unité de code avec un nom et un numéro qualifiés pour les unités de code avec des noms répétés. |
File Name |
Le nom du fichier dans lequel se trouve l’objet. Utilise le chemin relatif à partir du répertoire d’entrée. |
Numéro de ligne |
Le numéro de ligne dans le fichier où se trouve l’unité de code. |
Lignes de code |
Le nombre total de lignes de code de l’unité de code. |
Nombre d’EWI |
Le nombre d’EWIs trouvés dans l’unité de code. Vous pouvez en savoir plus sur les EWIs ici. |
Nombre de FDM |
Le nombre de FDMs trouvés dans l’unité de code. Vous pouvez en savoir plus sur les FDMs ici. |
Nombre de PRF |
La quantité de PRFs trouvée dans l’unité de code. Vous en apprendrez plus sur les PRFs ici. |
Valeur de gravité EWI la plus élevée |
<p>La valeur de gravité EWI la plus élevée trouvée dans l’unité de code.<br>L’ordre de gravité est le suivant :</p><ul><li>N/A (lorsqu’il n’y a pas d’EWIs)</li><li>Faible</li><li>Moyen</li><li>Élevé</li><li>Critique</li></ul> |
UDFs utilisés |
Les noms de toutes les fonctions définies par l’utilisateur qui se trouvent dans l’unité de code. Les noms des UDFs utilisés sont séparés par un canal s’il y en a plusieurs. |
EWI |
Les codes de tous les EWIs qui se trouvent dans l’unité de code. Ces codes sont séparés par des canaux et ne comprennent pas les codes répétés. |
FDM |
Les codes de tous les FDMs qui se trouvent dans l’unité de code. Ces codes sont séparés par des canaux et ne comprennent pas les codes répétés. |
PRF |
Les codes de tous les PRFs qui se trouvent dans l’unité de code. Ces codes sont séparés par des canaux et ne comprennent pas les codes répétés. |
Statut de conversion |
<p>Le statut final de la conversion de l’unité de code.</p><p>Les statuts de conversion possibles sont :</p><ul><li>NotSupported : Lorsque le taux de conversion de l’unité de code est de 0 %.</li><li>Partiel : Lorsque le taux de conversion de l’unité de code est compris entre 0 et 100 %.</li><li>Réussite : Lorsque le taux de conversion de l’unité de code est de 100 %.</li></ul> |
Pourcentage de conversion LoC |
Le pourcentage de conversion est basé sur les lignes de code. Une ligne de code unique peut comporter des fragments pris en charge et des fragments non pris en charge, en fonction du formatage du code d’entrée. Dans ces cas, la ligne entière est considérée comme non prise en charge. |
Ordre de déploiement |
L’ordre de déploiement est le niveau supérieur de chaque unité de code en fonction de ses dépendances. Il montre le bon ordre dans lequel les unités de code doivent être déployées afin d’éviter les dépendances manquantes pendant la phase de déploiement. |
Langage |
Le langage de programmation ou dialecte SQL de l’unité de code source. |
Exemple¶
Supposons que l’instruction CREATE TABLE suivante ORACLE SQL se trouve dans son fichier appelé table_example.sql.
CREATE TABLE my_table (
my_column DATE DEFAULT TO_DATE(CURRENT_DATE, 'J'),
NOT A VALID COLUMN
);
CREATE OR REPLACE TABLE my_table (
my_column TIMESTAMP /*** SSC-FDM-OR0042 - DATE TYPE COLUMN HAS A DIFFERENT BEHAVIOR IN SNOWFLAKE. ***/ DEFAULT PUBLIC.JULIAN_TO_GREGORIAN_DATE_UDF(CURRENT_DATE(), 'J')
-- ,
-- ** SSC-EWI-0001 - UNRECOGNIZED TOKEN ON LINE '3' COLUMN '3' OF THE SOURCE CODE STARTING AT 'NOT'. EXPECTED 'Column Definition' GRAMMAR. LAST MATCHING TOKEN WAS ',' ON LINE '2' COLUMN '52'. FAILED TOKEN WAS 'NOT' ON LINE '3' COLUMN '3'. CODE '15'. **
-- NOT A VALID COLUMN
)
COMMENT = '{"origin":"sf_sc","name":"snowconvert","version":{"major":1, "minor":0},"attributes":{"component":"oracle"}}'
;
Le rapport sur les unités de code de niveau supérieur ne comportera qu’une seule entrée de la table présentée précédemment.
Voici toutes les valeurs qui seront signalées dans l’entrée de cette instruction CREATE TABLE :
La valeur de la clé de partition dépendra de la migration, la valeur ici variera donc.
Le type de fichier sera SQL car il a été migré sur un fichier portant l’extension .sql.
La catégorie sera TABLE car l’instruction
CREATE TABLEfait partie de la catégorie d’unité de code TABLE.L”unité de code elle-même sera
CREATE TABLE.Le nom du fichier dans lequel cette unité de code a été trouvée est table_example.sql.
En supposant que l’instruction
CREATE TABLEse trouve au début du fichier, le numéro de ligne sera 1.Le nombre de lignes de code est 4.
La colonne Nombre d’EWI indique 1 car le code de sortie a un EWI en cours d’analyse.
La colonne Nombre de FDM indique 1 car le code de sortie présente un problème FDM lié aux types de données.
La colonne Nombre de PRF indique 0 car il n’y a pas de problème PRF dans le code de sortie.
Dans ce cas, la valeur de gravité de l’EWI la plus élevée est « Critique » car il s’agit de la valeur de gravité de l’EWI en cours d’analyse de l’exemple. Dans l’autre exemple, la valeur de gravité est « faible ».
La colonne UDFs utilisés est
JULIAN_TO_GREGORIAN_DATE_UDFcar cette fonction définie par l’utilisateur a été ajoutée pour convertir la fonctionTO_DATEdu code d’entrée.La colonne EWI indiquera « SSC-EWI-0001 « car il s’agit d’un des EWIs ajoutés dans le code de sortie.
La colonne FDM indiquera « SSC-FDM-OR0042 » car il s’agit d’un des FDMs ajoutés dans le code de sortie.
La colonne PRF indiquera « N/A » car il n’y a pas de problème PRF dans le code de sortie.
Le statut de conversion sera « Partiel » car seuls certains fragments de cette unité de code ont pu être migrés sans EWIs.
Le pourcentage de conversion LoC est de 50 % car sur 4 lignes, seules 2 ont été converties avec succès.
Ordre de déploiement¶
La colonne de l’ordre de déploiement représente l’ordre correct pour déployer chaque unité de code dans Snowflake.
Le code suivant illustre en détail la manière dont l’ordre de déploiement est calculé.
CREATE TABLE TABLE1 ( -- level 0, no dependencies
COL1 INT
);
CREATE TABLE TABLE2 ( -- level 0, no dependencies
COL1 INT
);
CREATE VIEW VIEW1 -- level 4, depends on level-3 objects
AS SELECT * FROM VIEW2, VIEW3;
CREATE VIEW VIEW2 -- level 3, depends on level-2 objects
AS SELECT * FROM VIEW4, VIEW5, VIEW3;
CREATE VIEW VIEW4 -- level 1, depends on level-0 objects
AS SELECT * FROM TABLE1, TABLE2;
CREATE VIEW VIEW5 -- level 1, depends on level-0 objects
AS SELECT * FROM TABLE1;
CREATE VIEW VIEW3 -- level 2, depends on level-1 objects
AS SELECT * FROM VIEW6;
CREATE VIEW VIEW6 -- level 1, depends on level-0 objects
AS SELECT * FROM TABLE2;
L’ordre de déploiement commence par 0, les unités de code sans aucune dépendance commenceront à ce niveau. Dans l’exemple ci-dessus, TABLE1 et TABLE2 auront un niveau 0 .
Pour le niveau suivant, nous nous concentrons sur les unités de code qui dépendent d’unités de code de niveau 0. VIEW4, VIEW5, et VIEW6 dépendent directement de TABLE1 et TABLE2, donc leur niveau sera 1.
Après avoir identifié toutes les unités de code de niveau 1 , nous nous concentrons sur les unités de code de niveau 2. Dans ce scénario particulier, seule VIEW3 dépend de VIEW6, donc VIEW3 sera un niveau 2.
Une fois que nous identifions toutes les unités de code de niveau 2, nous nous concentrerons sur le niveau 3. Dans l’exemple ci-dessus, VIEW2 dépend de VIEW4, VIEW5 et VIEW3, cependant, le niveau de dépendance le plus élevé est 2, donc, VIEW2 sera de niveau 3.#x20;
Enfin, nous avons obtenu VIEW1, qui dépend de VIEW2 et VIEW3. Depuis VIEW2 est la dépendance de niveau supérieur, VIEW1 obtiendra le niveau 4.#x20;
Après avoir effectué tous les calculs, le rapport sur les unités de code de niveau supérieur ressemblera au tableau suivant.
ID d’unité de code |
Ordre de déploiement |
|---|---|
VIEW1 |
4 |
VIEW2 |
3 |
VIEW3 |
2 |
VIEW4 |
1 |
VIEW5 |
1 |
VIEW6 |
1 |
TABLE1 |
0 |
TABLE2 |
0 |
Limitations¶
Il existe certains scénarios où l’ordre de déploiement peut ne pas calculer le bon niveau pour une unité de code spécifique.
Unités de code avec dépendances manquantes¶
Le déploiement d’unités de code qui dépendent (directement ou indirectement) d’objets manquants n’est pas possible. Bien que SnowConvert AI calcule l’ordre de déploiement au mieux, une dépendance manquante entraînera des erreurs de déploiement. Pour les unités de code avec des dépendances manquantes, SnowConvert AI ajoute un astérisque (*) à côté de l’ordre de déploiement. Par exemple
CREATE TABLE TABLE1 ( -- level 0, no dependencies
COL1 INT
);
CREATE VIEW VIEW1 -- level 1*, depends on level-0 objects and has a missing dependency
AS SELECT * FROM TABLE1, TABLE2;
CREATE VIEW VIEW2 -- level 2*, depends on level-1* objects
AS SELECT * FROM VIEW1;
L’exemple ci-dessus montre VIEW1 faisant référence à une TABLE2 manquante et VIEW2 faisant référence à VIEW1 qui renvoie indirectement TABLE2. VIEW1 dispose d’une référence manquante directe et VIEW2 d’une référence manquante indirecte. Le rapport d’unités de code de niveau supérieur ressemblera au tableau suivant.
ID d’unité de code |
Ordre de déploiement |
|---|---|
TABLE1 |
0 |
VIEW1 |
1* |
VIEW2 |
2* |
Unités de code référençant des liens de base de données (Oracle)¶
Alors que SnowConvert AI peut identifier les références aux liens de base de données, il ne peut pas obtenir plus d’informations sur les objets référencés par le biais du lien de base de données. Ce type de référence peut également causer des problèmes lors du déploiement, de sorte qu’il sera traité de la même manière que les références d’objet manquantes. Par exemple
CREATE DATABASE LINK DBLINK1
CONNECT TO PUBLIC IDENTIFIED BY VALUES ':1'
USING 'TEST';
CREATE MATERIALIZED VIEW VIEW1 REFRESH WITH ROWID
AS SELECT * FROM TABLE1@DBLINK1;
VIEW1 fait référence à TABLE1 via le lien de base de données DBLINK1. Comme nous ne saurons pas où TABLE1 est situé, l’ordre de déploiement de VIEW1 sera traité comme un ordre de déploiement sans dépendances manquantes (*).#x20;
ID d’unité de code |
Ordre de déploiement |
|---|---|
DBLINK1 |
0 |
VIEW1 |
1* |
Unités de code faisant référence aux DDLs définies dans les procédures stockées, les blocs anonymes, etc.¶
Dans certains scénarios, l’ordre de déploiement peut ne pas être correct, car l’élément référencé a été défini dans une autre unité de code. Par exemple
CREATE TABLE TABLE1 (
COL1 INT
);
CREATE OR REPLACE PROCEDURE PROC1 (param1 NUMBER)
IS
BEGIN
CREATE VIEW VIEW1
AS
SELECT * FROM TABLE1;
END;
CREATE VIEW VIEW2
AS SELECT * FROM VIEW1;
Dans le code ci-dessus, VIEW2 fait référence à VIEW1, qui sera créé après l’exécution de la procédure stockée. VIEW1 fait référence à TABLE1, la procédure doit donc être exécutée après la création de la table. Dans ce scénario particulier, VIEW1 ne sera pas inclus dans le rapport des unités de code de niveau supérieur, car il est contenu par la procédure stockée. Dans ce cas, pour VIEW2 n’est pas possible de savoir que VIEW1 dépend de PROC1 à créer, et l’ordre de déploiement peut ne pas être correct à cause de cela. Le tableau suivant indique l’ordre de déploiement du code ci-dessus.
ID d’unité de code |
Ordre de déploiement |
|---|---|
TABLE1 |
0 |
PROC1 |
1 |
VIEW2 |
1 |
Malgré VIEW1 et PROC1 ayant le même ordre de déploiement, VIEW1 échouera si la procédure n’a pas été exécutée en premier.
Avertissement
La prise en charge de l’ordre de déploiement pour les séquences sera disponible dans une future version. Par défaut, les unités de code faisant référence à des séquences ne les prennent pas en compte pour calculer l’ordre de déploiement.