Jak przestać robić to samo

Czy lubisz powtarzać rutynowe operacje za każdym razem? Ja nie. Ale za każdym razem w kliencie SQL podczas pracy z magazynem Rostelecom musiałem ręcznie wpisywać wszystkie złącza między tabelami. A to przy tym, że w 90% przypadków pola i warunki łączenia tabel były identyczne od zapytania do zapytania! Wydawałoby się, że każdy klient SQL ma funkcje autouzupełniania, ale dla magazynów nie zawsze to działa: rzadko tworzone są unikalne ograniczenia i klucze obce w celu zwiększenia wydajności, a bez tego program nie wie, jak między sobą powiązane są byty i co może ci zaproponować.

Przechodząc przez zaprzeczenie, złość, negocjacje, depresję i zbliżając się do akceptacji, postanowiłem — a dlaczego nie spróbować zaimplementować autouzupełniania z blackjackiem i właściwie? Korzystam z klienta dbeaver, napisanego w javie, ma wersję społecznościową z otwartym kodem źródłowym. Ułożyłem prosty plan:

1. Znaleźć w kodzie źródłowym klasy odpowiedzialne za autouzupełnianie
2. Przekierować je do pracy z zewnętrznymi metadanymi i pobierać stamtąd informacje o złączeniach
3. ??????
4. PROFIT

Z pierwszym punktem szybko sobie poradziłem — znalazłem w trackerze błędów zgłoszenie dotyczące korekty autouzupełniania i w powiązanym commicie odkryłem klasę SQLCompletionAnalyzer. Przejrzałem kod — to, czego potrzebowałem. Musiałem go tylko przepisać, aby wszystko działało. Czekałem na wolny wieczór i zacząłem planować realizację. Zasady powiązań tabel (metadane) postanowiłem prowadzić w formacie json. Nie miałem praktycznego doświadczenia w pracy z tym formatem, a obecne zadanie wydawało się szansą na naprawienie tej luki.

Do pracy z json postanowiłem użyć biblioteki json-simple od google. Tu zaczęły się niespodzianki. Okazało się, że dbeaver, jako prawdziwa aplikacja, został napisany na platformie eclipse z użyciem frameworka OSGi. Dla doświadczonych programistów ta rzecz zapewnia wygodę zarządzania zależnościami, dla mnie natomiast bardziej przypominała czarną magię, do której zdecydowanie nie byłem przygotowany: jak zwykle wpisałem import potrzebnych klas z biblioteki json-simple w nagłówku edytowanej klasy, wskazałem ją w pom.xml, a potem projekt kategorycznie odmówił prawidłowego złożenia i zawalił się z błędami.

Poprawienie błędów budowy polegało na tym, że zdefiniowałem bibliotekę nie w pom.xml, a w manifeście manifest.mf, tak jak wymaga OSGI, podając ją jako import-package. Nie jest to najpiękniejsze rozwiązanie, ale działa. Tutaj pojawiła się kolejna niespodzianka. Jeśli rozwijasz projekt w intellij idea, nie można po prostu wziąć i uruchomić debugowania swojego projektu opartego na platformie eclipse: niedoświadczony programista musi cierpieć nie mniej niż analityk bez autouzupełniania zapytań. Z pomocą przyszli sami twórcy bobra, wskazując w wiki wszystkie tańce z bębnem, które trzeba wykonać. Najbardziej frustrujące jest to, że nawet po wszystkich tych próbach projekt nie chciał uruchomić się w debugowaniu z podłączoną biblioteką json przez import-package (choć w gotowym produkcie wciąż udawało się go zbudować).

W międzyczasie poczułem niedogodność korzystania z json do mojego zadania — ostatecznie metadane miały być edytowane ręcznie, a do tego format xml lepiej pasuje. Drugim argumentem na korzyść 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 json do xml i przystąpiłem do poprawek logiki autouzupełniania.

Przykład metadanych

dim_account
        dim_partner
        
        
    
    
        dim_account
        dim_branch

W rezultacie wprowadziłem zmiany w klasach SQLUtils i SQLCompletionAnalyzer. Idea jest taka: jeśli program nie był w stanie dopasować odpowiednich propozycji autouzupełniania według podstawowej logiki, sprawdza obecność możliwych dołączeń w zewnętrznym pliku xml. W samym pliku przechowywane są pary tabel z określeniem pól, według których te tabele należy połączyć. Ograniczenia dotyczące technicznych dat obowiązywania rekordów eff_dttm i exp_dttm oraz flaga usunięcia logicznego deleted_ind są przy tym ustawiane domyślnie.

Kiedy wprowadzono zmiany w kodzie, pojawiło się pytanie — kto będzie uzupełniał plik z metadanymi? W magazynie jest wiele encji, samodzielne tworzenie wszystkich powiązań byłoby uciążliwe. Ostatecznie postanowiłem zlecić to zadanie moim kolegom analitykom. Plik metadanych umieściłem w svn, skąd odbywa się checkout do lokalnego katalogu z programem. Zasada jest taka: pojawiła się nowa encja w magazynie? Jeden analityk wprowadza możliwe połączenia do pliku, commituję zmiany, pozostali wykonują checkout do siebie i cieszą się działającym autouzupełnieniem: społeczność, gromadzenie wiedzy i tym podobne. Zorganizowałem warsztaty dla kolegów na temat korzystania z programu, napisałem artykuł w Confluence — teraz w firmie jest jeszcze jedno wygodne narzędzie.

Praca nad tą funkcją dała mi zrozumienie, że nie warto bać się grzebać w projektach open-source — zazwyczaj mają one przejrzystą architekturę, a nawet podstawowe umiejętności języka wystarczą do eksperymentów. Przy pewnej dozie determinacji można nawet pozbyć się nienawidzonych rutynowych operacji, oszczędzając czas na nowe eksperymenty.

Źródło: habr.com