Comment arrêter de faire la même chose

Aimez-vous répéter les opérations de routine de temps en temps? Me voici. Mais à chaque fois dans le client SQL lorsque je travaillais avec le référentiel Rostelecom, je devais enregistrer toutes les jointures entre les poignées des tables. Et cela malgré le fait que dans 90% des cas les champs et conditions de jonction des tables coïncidaient de requête en requête! Il semblerait que tout client SQL possède des fonctions de saisie semi-automatique, mais cela ne fonctionne pas toujours pour les stockages: ils ont rarement une contrainte unique et une clé étrangère afin d'améliorer les performances, et sans cela, le programme ne peut pas savoir comment les entités sont liées et ce qu'il peut faire pour vous. suggérer.



Ayant traversé le déni, la colère, les négociations, la dépression et l'approche de l'acceptation, j'ai décidé - pourquoi ne pas essayer de mettre en œuvre l'auto-complétion avec le blackjack moi-même et comme il se doit? J'utilise le client dbeaver écrit en java, il a une version communautaire open source. Un plan simple a mûri:

1. Rechercher des classes de saisie semi-automatique dans le code source
2. Réorientez-les pour travailler avec des métadonnées externes et extraire des informations sur les jointures à partir de là
3. ??????
4. PROFIT

J'ai rapidement trouvé le premier élément - j'ai trouvé une demande d'ajustement de la saisie automatique dans le bugtracker et j'ai trouvé la classe SQLCompletionAnalyzer dans le commit associé. J'ai regardé le code - ce dont j'ai besoin. Il reste à 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. Les règles de liaison de table (métadonnées) ont décidé de conduire dans json. Je n'avais aucune expérience pratique de ce format et la tâche en cours était considérée comme une opportunité de corriger cette omission.

Pour travailler avec json, j'ai décidé d'utiliser la bibliothèque json-simple de Google. Ici les surprises ont commencé. Il s'est avéré que dbeaver, en tant qu'application tru, est écrit sur la plateforme eclipse en utilisant le framework OSGi. Pour les développeurs expérimentés, cette chose donne la commodité de 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'enregistre l'importation des classes dont j'ai besoin depuis la bibliothèque json-simple dans l'en-tête de la classe éditée, je le spécifie dans pom. xml, après quoi le projet refuse catégoriquement de se réunir correctement et échoue avec des erreurs.

En conséquence, nous avons réussi à corriger les erreurs d'assembly: j'ai enregistré la bibliothèque non pas dans pom.xml, mais dans le manifeste manifest.mf, comme requis par OSGI, tout en la spécifiant en tant que package d'importation. Pas la plus belle solution, mais ça marche. Puis la prochaine surprise est apparue. Si vous développez dans intellij idea, vous ne pouvez pas simplement obtenir et exécuter le débogage de votre projet basé sur la plate-forme Eclipse: un développeur inexpérimenté ne devrait pas souffrir au moins un analyste sans autocomplétion des demandes. 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 ne voulait pas démarrer en débogage avec la bibliothèque json connectée via import-package (malgré le fait qu'il soit toujours assemblé avec succès dans le produit fini).

À ce moment-là, j'ai réussi à ressentir 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 pour cela, le format xml est mieux adapté. Le deuxième argument en faveur de xml était la présence dans le JDK de toutes les classes nécessaires, ce qui a permis d'arrêter de se battre avec une bibliothèque externe. Avec grand plaisir, j'ai transféré toutes les métadonnées de json vers xml et j'ai procédé à l'édition de la logique de saisie semi-automatique.



Par conséquent, j'ai apporté des modifications aux classes SQLUtils et SQLCompletionAnalyzer. L'idée est la suivante: si le programme n'a pas réussi à trouver des phrases d'auto-complétion appropriées selon la logique de base, il vérifie les jointures possibles à l'aide d'un fichier xml externe. Le fichier lui-même contient des paires de tables indiquant les champs par lesquels ces tables doivent être liées. Les restrictions sur les dates de validité technique des entrées eff_dttm et exp_dttm et l'indicateur de suppression logique supprimé_ind sont définis par défaut.

Lorsque des modifications ont été apportées au code, la question s'est posée - qui remplira le fichier de métadonnées? Il y a beaucoup d'entités dans le référentiel; il n'est pas rentable d'enregistrer toutes les connexions vous-même. Finalement, j'ai décidé de suspendre cette tâche à mes collègues analystes. Le fichier de métadonnées a été téléchargé sur svn, d'où les extractions sont effectuées dans un répertoire local avec le programme. Le principe est le suivant: une nouvelle entité est apparue dans le référentiel? Un analyste rend possible les jointures à un fichier, valide les modifications, les autres effectuent des vérifications pour eux-mêmes et aiment travailler la saisie semi-automatique: communauté, accumulation de connaissances et tout cela. Tenu un atelier pour les collègues sur l'utilisation du programme, a écrit un article en confluence - maintenant, la société a plus d'un outil pratique.

Le travail sur cette fonctionnalité m'a permis de comprendre qu'il ne fallait pas avoir peur de choisir 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 un certain degré de persévérance, vous pouvez même vous débarrasser des opérations de routine détestées, vous épargnant du temps pour de nouvelles expériences.