Wie man aufhört, immer dasselbe zu tun

Haben Sie es auch satt, immer wieder die gleichen Routineaufgaben durchzuführen? Ich schon. Doch jedes Mal, wenn ich mit dem Speichersystem von Ростелеком in meinem SQL-Client gearbeitet habe, musste ich alle Joins zwischen den Tabellen manuell eingeben. Dabei waren in 90 % der Fälle die Felder und Bedingungen für die Verknüpfungen identisch von Abfrage zu Abfrage! Es scheint, dass jeder SQL-Client über Auto-Vervollständigungsfunktionen verfügt, aber für Speicher funktioniert das nicht immer: Dort werden selten unique constraints und foreign keys eingerichtet, um die Leistung zu steigern, und ohne diese kann das Programm nicht erkennen, wie die Entitäten miteinander verbunden sind und was es dir anbieten kann.

Nachdem ich durch Verleugnung, Wut, Verhandlungen, Depressionen gegangen bin und mich der Akzeptanz nähere, habe ich beschlossen – warum nicht selbst versuchen, die Auto-Vervollständigung mit einem Hauch von Blackjack ordentlich zu implementieren? Ich benutze den dbeaver-Client, der in Java geschrieben ist und eine Community-Version mit offenem Quellcode hat. Ein einfacher Plan ist gereift:

1. Die Klassen im Quellcode finden, die für die Auto-Vervollständigung verantwortlich sind
2. Diese auf externe Metadaten umschulen und Informationen über Joins von dort abrufen
3. ??????
4. PROFIT

Mit dem ersten Punkt war ich schnell fertig – ich fand im Bugtracker den Antrag zur Anpassung der Autovervollständigung und im dazugehörigen Commit. Ich entdeckte die Klasse SQLCompletionAnalyzer. Ich schaute mir den Code an – genau das, was ich brauchte. Jetzt musste ich ihn nur so umschreiben, dass alles funktionierte. Ich wartete auf einen freien Abend und begann, die Implementierung zu durchdenken. Die Regeln für die Tabellenbeziehungen (Metadaten) wollte ich in JSON führen. Ich hatte keine praktische Erfahrung mit diesem Format, und die aktuelle Aufgabe erschien mir als Gelegenheit, dieses Defizit auszugleichen.

Für die Arbeit mit JSON entschied ich mich, die Bibliothek json-simple von Google zu verwenden. Hier begannen die Überraschungen. Wie sich herausstellte, ist dbeaver, als echtes Tool, auf der Eclipse-Plattform mit dem OSGi-Framework geschrieben. Für erfahrene Entwickler bietet diese Sache eine bequeme Abwicklung von Abhängigkeiten, für mich fühlte es sich jedoch mehr wie schwarze Magie an, auf die ich eindeutig nicht vorbereitet war: Wie gewohnt importierte ich die benötigten Klassen aus der Bibliothek json-simple im Kopf der bearbeiteten Klasse, wies sie in pom.xml aus, nachdem das Projekt kategorisch die normale Erstellung verweigerte und mit Fehlern abstürzte.

Die Korrekturen der Kompilierungsfehler ergaben letztendlich: Ich hatte die Bibliothek nicht in der pom.xml, sondern im Manifest manifest.mf eingetragen, wie es OSGI verlangt, und sie als import-package deklariert. Keine besonders schöne Lösung, aber sie funktioniert. Dann kam die nächste Überraschung. Wenn du in IntelliJ IDEA entwickelst, kannst du dein auf Eclipse basierendes Projekt nicht einfach debuggen: Ein unerfahrener Entwickler muss genauso leiden wie ein Analyst ohne Autocomplete für Anfragen. Die Entwickler von Beaver halfen, indem sie in der Wiki alle notwendigen Schritte dokumentiert haben. Das Frustrierenste war, dass selbst nach all diesen Anstrengungen das Projekt im Debugger mit der über import-package hinzugefügten JSON-Bibliothek nicht starten wollte (trotz der Tatsache, dass es im fertigen Produkt weiterhin erfolgreich gebaut wurde).

Bis zu diesem Zeitpunkt hatte ich das Unbehagen festgestellt, 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 das Vorhandensein aller notwendigen Klassen im JDK, was mir ermöglichte, den Kampf mit einer externen Bibliothek zu beenden. Mit großer Freude habe ich alle Metadaten von JSON nach XML übertragen und mit den Anpassungen der Auto-Vervollständigungslogik begonnen.

Beispiel für Metadaten

dim_account
        dim_partner
        
        
    
    
        dim_account
        dim_branch

Infolgedessen habe ich Änderungen vorgenommen in den Klassen SQLUtils und SQLCompletionAnalyzer. Die Idee ist die folgende: Wenn das Programm keine passenden Autovervollständigungs Vorschläge basierend auf der grundlegenden Logik finden kann, überprüft es das Vorhandensein möglicher Joins über eine externe XML-Datei. In der Datei sind Tabellenpaare mit den entsprechenden Feldern gespeichert, die die Tabellen verknüpfen müssen. Einschränkungen für die technischen Datumsangaben der Datensätze eff_dttm und exp_dttm sowie das Flag des logischen Löschens deleted_ind werden dabei standardmäßig gesetzt.

Nachdem Änderungen am Code vorgenommen wurden, stellte sich die Frage – wer wird die Metadatendatei ausfüllen? Es gibt viele Entitäten im Speicher, und es ist aufwendig, alle Beziehungen manuell einzutragen. Letztendlich habe ich beschlossen, diese Aufgabe an meine Kollegen im Analytik-Team zu delegieren. Die Metadatendatei habe ich in das SVN hochgeladen, von wo aus ein Checkout in das lokale Verzeichnis mit dem Programm erfolgt. Das Prinzip ist einfach: Gibt es eine neue Entität im Speicher? Ein Analyst trägt mögliche Joins in die Datei ein, committet die Änderungen, und die anderen machen einen Checkout zu sich und genießen die automatische Vervollständigung: Gemeinschaft, Wissensansammlung und all das. Ich habe einen Workshop für meine Kollegen zur Nutzung des Programms durchgeführt und einen Artikel in Confluence verfasst – jetzt haben wir ein weiteres nützliches Werkzeug in der Firma.

Die Arbeit an diesem Feature hat mir gezeigt, dass man keine Angst haben sollte, an Open-Source-Projekten herumzuprobieren – in der Regel haben sie eine klare Architektur, und selbst grundlegende Kenntnisse der Sprache sind ausreichend für experimentelle Vorhaben. Mit ein wenig Hartnäckigkeit kann man sogar lästige Routineaufgaben eliminieren und sich Zeit für neue Experimente sparen.

Quelle: habr.com