Wie man aufhört, immer dasselbe zu tun.

Mögen Sie es, routinemäßige Aufgaben immer wieder zu wiederholen? Ich nicht. Aber jedes Mal, wenn ich im SQL-Client mit dem Speicher von Rostelecom arbeite, musste ich alle Joins zwischen den Tabellen manuell eingeben. Und das, obwohl in 90 % der Fälle die Felder und Bedingungen für die Joins von Anfrage zu Anfrage übereinstimmten! Es scheint, dass jeder SQL-Client Autovervollständigungsfunktionen hat, aber für Speicher funktioniert das nicht immer: In ihnen werden selten unique constraints und foreign keys zur Leistungsteigerung eingerichtet, und ohne diese kann das Programm nicht wissen, wie die Entitäten miteinander verbunden sind und was es dir anbieten kann.

Nach dem Durchlaufen von Negation, Wut, Verhandlung, Depression und dem Hinzukommen zur Akzeptanz dachte ich: Warum nicht selbst versuchen, die Autovervollständigung mit Blackjack und allem Drum und Dran zu implementieren? Ich benutze den Client dbeaver, der in Java geschrieben ist und eine Community-Version mit Open-Source hat. Ein einfacher Plan reifte:

1. Die Klassen im Quellcode zu finden, die für die Autovervollständigung verantwortlich sind.
2. Sie auf die Arbeit mit externen Metadaten umzustellen und Informationen über Joins von dort abzurufen.
3. ??????
4. PROFIT

Mit dem ersten Punkt habe ich mich recht schnell angefreundet – ich fand im Bugtracker eine Anfrage zur Korrektur der Autovervollständigung und in dem zugehörigen Commit entdeckte ich die Klasse SQLCompletionAnalyzer. Ich schaute mir den Code an – genau das, was ich brauchte. Es blieb nur noch, ihn so umzuschreiben, dass alles funktionierte. Ich wartete auf einen freien Abend und begann, die Implementierung zu planen. Die Regeln für die Beziehungen der Tabellen (Metadaten) wollte ich im JSON-Format festhalten. Ich hatte keine praktische Erfahrung mit diesem Format und die aktuelle Aufgabe schien mir eine Möglichkeit zu sein, diese Lücke zu schließen.

Für die Arbeit mit JSON wollte ich die Bibliothek json-simple von Google verwenden. Hier begannen die Überraschungen. Wie sich herausstellte, ist dbeaver, als echtes Programm, auf der Eclipse-Plattform unter Verwendung des OSGi-Frameworks geschrieben. Für erfahrene Entwickler bietet dieses Ding einen bequemen Umgang mit Abhängigkeiten, während es für mich eher wie dunkle Magie wirkte, auf die ich offensichtlich nicht vorbereitet war: Wie üblich importierte ich die benötigten Klassen aus der json-simple-Bibliothek im Header der bearbeiteten Klasse, gab sie in der pom.xml an, woraufhin das Projekt kategorisch aufhörte, sich normal zu bauen und mit Fehlern abstürzte.

Die Fehlerbehebung des Build-Problems führte dazu, dass ich die Bibliothek nicht in pom.xml, sondern im Manifest manifest.mf angegeben habe, wie es OSGI verlangt und sie als import-package deklariert habe. Es ist nicht die schönste Lösung, aber sie funktioniert. Dann kam die nächste Überraschung. Wenn du Entwicklung in Intellij IDEA machst, kannst du dein Eclipse-basiertes Projekt nicht einfach debuggen: Ein unerfahrener Entwickler muss ebenso leiden wie ein Analyst ohne Autovervollständigung von Anfragen. Glücklicherweise haben die Entwickler von Beaver in der Wiki alle Schritte erwähnt, die nötig sind. Das Frustrierendste ist, dass das Projekt nach all diesen Schritten immer noch nicht im Debugging mit der über import-package eingebundenen JSON-Bibliothek starten wollte (obwohl es im Endprodukt weiterhin erfolgreich kompiliert wurde).

Zu diesem Zeitpunkt hatte ich bereits das Unbehagen gespürt, JSON für meine Aufgabe zu verwenden – schließlich sollten die Metadaten manuell bearbeitet werden, und dafür eignet sich das XML-Format besser. Ein weiteres Argument für XML war, dass alle notwendigen Klassen in der JDK vorhanden waren, was mir die Auseinandersetzung mit einer externen Bibliothek ersparte. Mit großer Freude habe ich alle Metadaten von JSON nach XML übertragen und mit der Anpassung der Autovervollständigungslogik begonnen.

Beispiel für Metadaten

dim_account
        dim_partner
        
        
    
    
        dim_account
        dim_branch

Als Ergebnis habe ich Änderungen vorgenommen in die Klassen SQLUtils und SQLCompletionAnalyzer. Die Idee ist folgende: Wenn die Software es nicht schafft, passende Vorschläge zur Autovervollständigung nach der Grundlogik zu finden, überprüft sie das Vorhandensein möglicher Joins aus einer externen XML-Datei. In der Datei werden Tabellenpaare mit den Feldern gespeichert, nach denen diese Tabellen verknüpft werden müssen. Die Einschränkungen für technische Datensätze der Gültigkeitsdaten eff_dttm und exp_dttm sowie das Flag für logisches Löschen deleted_ind werden standardmäßig festgelegt.

Nachdem Änderungen am Code vorgenommen wurden, stellte sich die Frage – wer wird die Metadatendatei ausfüllen? Im Speicher gibt es viele Entitäten, es ist umständlich, alle Verbindungen selbst zu erstellen. Schließlich habe ich beschlossen, diese Aufgabe meinen Kollegen aus der Analyseabteilung zu übertragen. Ich habe die Metadatendatei in SVN abgelegt, von wo aus ein Checkout in das lokale Verzeichnis mit dem Programm erfolgt. Das Prinzip ist folgendes: Gibt es eine neue Entität im Speicher? Ein Analyst fügt die möglichen Joins in die Datei ein, committet die Änderungen, die anderen holen sich den Checkout und genießen die funktionierende automatische Vervollständigung: Gemeinschaft, Wissen ansammeln und so weiter. Ich habe für meine Kollegen einen Workshop zur Verwendung des Programms durchgeführt, einen Artikel in Confluence geschrieben – jetzt hat das Unternehmen ein weiteres nützliches Tool.

Die Arbeit an diesem Feature hat mir das Verständnis gegeben, dass man keine Angst haben sollte, an Open-Source-Projekten zu basteln – in der Regel haben sie eine verständliche Architektur, und selbst grundlegende Sprachkenntnisse reichen für Experimente aus. Mit einem gewissen Maß an Beharrlichkeit kann man sogar die lästigen Routineaufgaben loswerden und sich Zeit für neue Experimente sparen.

Quelle: habr.com