Vous aimez répéter encore et encore les opérations de routine ? Donc je ne le fais pas. Mais à chaque fois dans le client SQL, lorsque je travaillais avec le stockage Rostelecom, je devais enregistrer manuellement toutes les jointures entre les tables. Et ce malgré le fait que dans 90% des cas les champs et conditions de jointure des tables coïncidaient d'une requête à l'autre ! Il semblerait que tout client SQL dispose de fonctions d'auto-complétion, mais pour les stockages, cela ne fonctionne pas toujours : ils incluent rarement une contrainte unique et une clé étrangère afin d'améliorer les performances, et sans cela, le programme ne saura pas comment les entités sont liées à chacune. autre et ce qu'il peut faire pour vous offrir.
Après avoir traversé le déni, la colère, le marchandage, la dépression et l'acceptation imminente, j'ai décidé : pourquoi ne pas essayer de mettre en œuvre moi-même le remplissage automatique avec le blackjack et le faire de la bonne manière ? J'utilise le client dbeaver, écrit en java, il a une version communautaire open source. Un plan simple a mûri :
- Rechercher les classes dans le code source qui sont responsables de la saisie semi-automatique
- Redirigez-les pour qu'ils travaillent avec des métadonnées externes et extrayez des informations sur les jointures à partir de là
- ??????
- PROFIT
J'ai compris le premier point assez rapidement - j'ai trouvé une demande dans le bug tracker pour ajuster le remplissage automatique et dans le découvert la classe SQLCompletionAnalyzer. J'ai regardé le code et c'est ce dont j'ai besoin. Il ne reste plus qu'à le réécrire pour que tout fonctionne. J'ai attendu une soirée libre et j'ai commencé à réfléchir à la mise en œuvre. J'ai décidé d'écrire des règles de liens de table (métadonnées) en json. Je n'avais aucune expérience pratique de travail avec ce format et la tâche actuelle était considérée comme une opportunité de corriger cette omission.
Pour travailler avec json, j'ai décidé d'utiliser la bibliothèque de Google. C'est là que les surprises ont commencé. Il s'est avéré que dbeaver, en tant que véritable application, a été écrite sur la plate-forme Eclipse en utilisant le framework OSGi. Pour les développeurs expérimentés, cette chose facilite la gestion des dépendances, mais pour moi, cela ressemblait plus à de la magie noire, pour laquelle je n'étais clairement pas prêt : comme d'habitude, j'importe les classes dont j'ai besoin depuis la bibliothèque json-simple dans l'en-tête de la classe éditée, précisez-la dans le pom.xml, après quoi le projet refuse catégoriquement de s'assembler normalement et plante avec des erreurs.
Au final, j'ai réussi à corriger les erreurs de build : j'ai enregistré la bibliothèque non pas dans pom.xml, mais dans le manifeste manifest.mf, comme l'exige OSGI, tout en la spécifiant comme import-package. Ce n'est pas la plus belle solution, mais ça marche. Puis la surprise suivante est apparue. Si vous développez dans Intellij Idea, vous ne pouvez pas simplement commencer à déboguer votre projet basé sur la plate-forme Eclipse : un développeur inexpérimenté ne devrait pas moins souffrir qu'un analyste sans achèvement de requête. Les développeurs de castors eux-mêmes sont venus à la rescousse, indiquant dans le wiki toutes les danses avec un tambourin à faire. Le plus ennuyeux est que même après tous ces squats, le projet n'a pas voulu être lancé en débogage avec la bibliothèque json connectée via import-package (malgré le fait qu'elle ait quand même été assemblée avec succès dans le produit fini).
À ce moment-là, j'avais déjà réalisé l'inconvénient d'utiliser json pour ma tâche - après tout, les métadonnées étaient censées être modifiées manuellement et le format XML est mieux adapté pour cela. Le deuxième argument en faveur du XML était la présence de toutes les classes nécessaires dans le JDK, ce qui permettait d'arrêter de se battre avec une bibliothèque externe. C'est avec grand plaisir que j'ai transféré toutes les métadonnées de json vers xml et commencé à éditer la logique de saisie semi-automatique.
Exemple de métadonnées
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<tableRelations>
<tableRelation>
<leftTable>dim_account</leftTable>
<rightTable>dim_partner</rightTable>
<joinColumnPair leftColumn="partner_key" rightColumn="partner_key"/>
<joinColumnPair leftColumn="src_id" rightColumn="src_id"/>
</tableRelation>
<tableRelation>
<leftTable>dim_account</leftTable>
<rightTable>dim_branch</rightTable>
<joinColumnPair leftColumn="src_id" rightColumn="src_id"/>
<joinColumnPair leftColumn="branch_key" rightColumn="branch_key"/>
</tableRelation>
</tableRelations>En conséquence, je dans les classes SQLUtils et SQLCompletionAnalyzer. L'idée est la suivante : si le programme n'est pas parvenu à trouver des suggestions de saisie semi-automatique appropriées en utilisant la logique de base, il vérifie alors la présence de jointures possibles à l'aide d'un fichier XML externe. Le fichier lui-même stocke des paires de tables indiquant les champs par lesquels ces tables doivent être liées. Les restrictions sur les dates de validité technique des enregistrements eff_dttm et exp_dttm et l'indicateur de suppression logique delete_ind sont définies par défaut.
Lorsque des modifications ont été apportées au code, la question s'est posée : qui remplira le fichier avec des métadonnées ? Il y a beaucoup d'entités dans le référentiel, cela coûte cher d'enregistrer toutes les connexions vous-même. En conséquence, j'ai décidé de confier cette tâche à mes collègues analystes. J'ai posté le fichier de métadonnées dans svn, à partir duquel une extraction est effectuée vers le répertoire local avec le programme. Le principe est le suivant : une nouvelle entité est-elle apparue dans le référentiel ? Un analyste saisit les jointures possibles dans le fichier, valide les modifications, les autres vérifient par eux-mêmes et profitent de l'auto-complétion fonctionnelle : communauté, accumulation de connaissances et tout ça. J'ai organisé un atelier sur l'utilisation du programme pour mes collègues et écrit un article dans Confluence. L'entreprise dispose désormais d'un outil plus pratique.
Travailler sur cette fonctionnalité m'a fait comprendre qu'il n'y a pas lieu d'avoir peur de bricoler des projets open source - en règle générale, ils ont une architecture claire et même une connaissance de base du langage suffira pour les expériences. Et avec une certaine persévérance, vous pourrez même vous débarrasser des opérations de routine détestées, économisant ainsi du temps pour de nouvelles expériences.
Source: habr.com