Jak przestać robić to samo

Czy lubisz powtarzać rutynowe czynności? Więc nie. Ale za każdym razem, gdy korzystałem z klienta SQL podczas pracy z pamięcią Rostelecom, musiałem ręcznie rejestrować wszystkie połączenia między tabelami. I to pomimo faktu, że w 90% przypadków pola i warunki łączenia tabel pokrywały się w poszczególnych zapytaniach! Wydawałoby się, że każdy klient SQL ma funkcje automatycznego uzupełniania, ale w przypadku magazynów nie zawsze to działa: rzadko zawierają unikalne ograniczenie i klucz obcy w celu poprawy wydajności, a bez tego program nie będzie wiedział, w jaki sposób jednostki są ze sobą powiązane inne i co może dla Ciebie zrobić.

Po przejściu przez zaprzeczanie, złość, targowanie się, depresję i zbliżanie się do akceptacji, zdecydowałem – dlaczego nie spróbować samodzielnie wdrożyć autouzupełniania w blackjacku i zrobić tego we właściwy sposób? Używam klienta dbeaver, napisanego w Javie, ma on wersję społecznościową typu open source. Opracowano prosty plan:

1. Znajdź w kodzie źródłowym klasy odpowiedzialne za autouzupełnianie
2. Przekieruj ich do pracy z zewnętrznymi metadanymi i stamtąd pobierz informacje o połączeniach
3. ???
4. ZYSK

Dość szybko zorientowałem się w pierwszym punkcie - znalazłem w narzędziu do śledzenia błędów prośbę o dostosowanie autouzupełniania i w powiązanych popełniać odkrył klasę SQLCompletionAnalyzer. Spojrzałem na kod i to jest to, czego potrzebuję. Pozostaje tylko napisać to od nowa, żeby wszystko działało. Poczekałem na wolny wieczór i zacząłem zastanawiać się nad realizacją. Postanowiłem napisać reguły łączenia tabel (metadane) w jsonie. Nie miałem praktycznego doświadczenia w pracy z tym formatem, a obecne zadanie było postrzegane jako szansa na naprawienie tego zaniedbania.

Do pracy z jsonem zdecydowałem się skorzystać z biblioteki json – proste z Google'a. Tu zaczęły się niespodzianki. Jak się okazało, dbeaver, jako prawdziwa aplikacja, został napisany na platformie Eclipse z wykorzystaniem frameworka OSGi. Doświadczonym programistom ułatwia to zarządzanie zależnościami, ale dla mnie było to bardziej jak czarna magia, na którą najwyraźniej nie byłem gotowy: jak zwykle importuję potrzebne mi klasy z biblioteki json-simple w nagłówku edytowaną klasę, określ ją w pom.xml, po czym projekt kategorycznie odmawia normalnego montażu i zawiesza się z błędami.

W końcu udało mi się naprawić błędy kompilacji: zarejestrowałem bibliotekę nie w pom.xml, ale w manifeście manifest.mf, zgodnie z wymaganiami OSGI, określając ją jako pakiet importowy. Nie jest to najpiękniejsze rozwiązanie, ale działa. Potem pojawiła się kolejna niespodzianka. Jeśli programujesz w Intellij Idea, nie możesz po prostu zacząć debugować swojego projektu w oparciu o platformę Eclipse: niedoświadczony programista powinien cierpieć nie mniej niż analityk bez zakończenia zapytania. Na ratunek przyszli sami twórcy bobrów, wskazując na wiki wszystkie tańce z tamburynem, które należy wykonać. Najbardziej irytujące jest to, że nawet po tych wszystkich przysiadach projekt nie chciał zostać uruchomiony w trybie debugowania z biblioteką json połączoną poprzez pakiet importowy (pomimo tego, że nadal udało się go pomyślnie zmontować w gotowy produkt).

Już wtedy zdałem sobie sprawę z niedogodności używania jsona do mojego zadania - w końcu metadane miały być edytowane ręcznie, a format xml lepiej się do tego nadaje. Drugim argumentem za xml była obecność w JDK wszystkich niezbędnych klas, co pozwoliło zakończyć walkę z zewnętrzną biblioteką. Z wielką przyjemnością przeniosłem wszystkie metadane z jsona do xml i zacząłem edytować logikę autouzupełniania.

Przykład metadanych

<?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>

W efekcie I dokonane zmiany do klas SQLUtils i SQLCompletionAnalyzer. Pomysł jest taki: jeśli program nie był w stanie znaleźć odpowiednich sugestii autouzupełniania przy użyciu podstawowej logiki, sprawdza obecność możliwych złączeń za pomocą zewnętrznego pliku xml. Sam plik przechowuje pary tabel wskazujące pola, za pomocą których te tabele muszą być połączone. Domyślnie ustawione są ograniczenia dotyczące dat ważności technicznej rekordów eff_dttm i exp_dttm oraz flaga usunięcia logicznego Deleted_ind.

Kiedy wprowadzono zmiany w kodzie, pojawiło się pytanie – kto wypełni plik metadanymi? Podmiotów w repozytorium jest bardzo dużo, samodzielna rejestracja wszystkich połączeń jest kosztowna. W rezultacie zdecydowałem się powierzyć to zadanie innym analitykom. Opublikowałem plik metadanych w svn, skąd następuje pobranie do lokalnego katalogu z programem. Zasada jest taka: czy w repozytorium pojawił się nowy podmiot? Jeden analityk wprowadza do pliku możliwe połączenia, zatwierdza zmiany, reszta sprawdza sama i cieszy się działającym autouzupełnianiem: społeczność, gromadzenie wiedzy i tak dalej. Przeprowadził dla współpracowników warsztaty z obsługi programu, napisał artykuł w Confluence – teraz firma ma jedno wygodniejsze narzędzie.

Praca nad tą funkcją dała mi zrozumienie, że nie trzeba bać się majstrować przy projektach open source - z reguły mają one przejrzystą architekturę i do eksperymentów wystarczy nawet podstawowa znajomość języka. Przy odrobinie wytrwałości będziesz w stanie nawet pozbyć się znienawidzonych rutynowych operacji, oszczędzając czas na nowe eksperymenty.

Źródło: www.habr.com