JetBrains – Travailler avec le code source dans DataGrip

Le code source de l’objet est la partie principale du script DDL(Data Definition Language : partie du SQL permettant de créer, modifier et supprimer les objets bases de données) qui est nécessaire pour créer cet objet. En d’autres termes, l’instruction CREATE ne fait pas partie du code source de l’objet. Le code source est stocké dans la base de données. Les objets les plus courants dans le code source sont les vues, les fonctions et les procédures stockées.

Pour mettre à jour le code source, de nombreux outils requièrent de générer le script CREATE OR REPLACE , d’effectuer les modifications nécessaires et d’exécuter le script. Dans Datagrip, cela fonctionne différemment. Il vous suffit d’effectuer les modifications et le script sera généré pour vous.

Les personnes utilisant d’autres outils font toutes la même chose : elles ouvrent le DDL, le copient, le modifient, ajustent la déclaration CREATE (généralement en ajoutant la partie OR REPLACE ) et exécutent le nouveau script. Ce n’est pas la manière de procéder pour mettre à jour le code source

Quelle que soit la source de données, DataGrip exécute un processus « d’introspection » – l’IDE récupère toutes les métadonnées des objets à l’avance. Ainsi, l’ensemble du code source est chargé lorsque l’introspection est effectuée.

Vous pouvez gérer ce processus en choisissant la valeur requise dans les options Load Sources for des propriétés de la source de données.

Dans Oracle, il est possible de ne pas charger les sources en choisissant un niveau d’introspection inférieur :

Vous vous demandez peut-être : si le code source est chargé lors de l’introspection, cela ne signifie-t-il pas qu’il est obsolète ?

En effet, il l’est. Nous verrons comment gérer cette situation plus tard dans ce tutoriel.

Pour ouvrir l’éditeur DDL, double-cliquez sur l’objet dans l’explorateur de base de données ou appuyez sur Cmd/Ctrl+B dans le script SQL. Double-cliquer sur la vue dans l’explorateur de bases de données ouvrira les données. Pour ouvrir l’explorateur DDL, cliquez sur le bouton DDL dans la barre d’outils.

L’éditeur DDL s’ouvrira. Là, vous trouverez le script CREATE pour l’objet.

Important ! Les références de l’objet dans le script généré ne sont pas qualifiées. En d’autres termes, %view_name% est utilisé à la place de %schema_name%.%view_name%. Vous avez ainsi la possibilité de copier le script et de l’appliquer dans un autre contexte. Si vous voulez un script avec des références qualifiées, utilisez le générateur SQL.

Le code source peut être modifié dans l’éditeur DDL. Lorsque vous modifiez le code source d’un objet, DataGrip suit les modifications et les met en évidence dans la gouttière.

Ajoutez par exemple une ligne de commentaire à une procédure ou à une fonction. La ligne que vous avez ajoutée est mise en évidence. Si vous cliquez sur la ligne mise en évidence dans la gouttière, une petite barre d’outils avec le bouton Show Diff s’affiche. Pour voir la différence entre le code que vous avez ajouté et le code source, cliquez sur le bouton Show Diff.

Après avoir effectué les modifications, cliquez sur le bouton Submit.

DataGrip génère alors le script de modification et vous en montre un aperçu.

Si le résultat vous convient, cliquez sur OK et le script sera exécuté dans la base de données. Le code source concerné sera alors modifié.

DataGrip ne fait pas qu’ajouter OR REPLACE au script de création, il peut également gérer des situations plus complexes, telles que la modification de la signature de l’objet ou le renommage de l’objet. Des scripts DROP et CREATE seront créés quand cela sera nécessaire.

Lorsque des modifications ont été effectuées dans l’éditeur DDL mais qu’elles ne sont pas encore validées, DataGrip les stocke jusqu’à ce que vous le fassiez. Par exemple, si vous avez modifié plusieurs objets, plusieurs DDL modifiés sont mis en cache en attendant d’être appliqués. Dans la fenêtre d’outils Database Changes, vous pouvez voir toutes les modifications de code source en attente et toutes les valider simultanément.

Comme nous l’avons mentionné plus haut, DataGrip met en cache le code source qui a été chargé lors de l’introspection. Si un objet que vous avez ouvert a été mis à jour depuis un emplacement tiers, vous recevrez une notification indiquant que l’objet mis en cache diffère du code source du même objet dans la base de données.

Si cet avertissement apparaît dans l’IDE, vous pouvez choisir l’une des actions suivantes :

• Synchronize : récupère les modifications de la base de données et met à jour l’objet local mis en cache ;
• Disable check : désactive cette notification.

Il est aussi possible qu’il y ait un conflit entre votre version du code source de l’objet et celle de la base de données. Cela peut se produire par exemple lorsque vous avez modifié le même code source qu’une autre personne, puis cliqué sur Submit.

Vous pouvez forcer le remplacement du code source de l’objet dans la base de données en utilisant Force Refactoring ou synchroniser l’état de l’objet et procéder ensuite aux modifications en cliquant sur Abort Refactoring and Synchronize.

Si vous avez sélectionné Abort Refactoring and Synchronize, DataGrip abandonne l’opération d’envoi et récupère les modifications de la base de données, tout comme si vous aviez cliqué sur Synchronize. Si le conflit existe toujours, vous verrez la notification suivante.

Dans cette notification, vous pouvez choisir entre plusieurs options :

• Revert local changes : pour annuler toutes vos modifications et les remplacer par la version de la base de données ;
• Keep local changes : pour utiliser vos modifications et écraser les modifications dans la base de données ;
• Merge : pour afficher la boîte de dialogue Diff et fusionner les versions du code source de l’objet.

Toutes les modifications que vous apportez au code source sont stockées localement. Pour revenir en arrière et vérifier le code source de la fonction avant les dernières mises à jour, utilisez Local History.

Dans Local History, les révisions contiennent toutes vos modifications locales et incluent également les versions récupérées dans la base de données lors des introspections. Ainsi, les versions de l’objet qui ont été introduites à partir de sources tierces et qui n’ont pas été « chargées » pendant l’introspection peuvent manquer. Vous pouvez comparer toute révision historique avec la version actuelle du code source.

Si vous êtes la seule personne qui travaille avec une base de données particulière et que vous modifiez les sources uniquement à partir de DataGrip, vous disposez d’un historique complet des modifications des objets dans Local History.

Et voilà ! Nous avons conscience que ce flux peut paraître surprenant, surtout si vous avez l’habitude d’utiliser un outil différent, mais il vous simplifiera la tâche en supprimant les opérations répétitives.

L’Équipe DataGrip.

P.S. Le modèle de couleurs utilisé pour les captures d’écran est Monocai.

Nous tenons à remercier Malick pour la mise au gabarit et escartefigue pour la relecture orthographique.