Nemáte radi neustále opakovať rutinné operácie? Ani ja nie. Ale zakaždým pri práci s úložiskom Rostelecom v SQL klientovi som musel ručne zapísať všetky spojenia medzi tabuľkami. A to aj napriek tomu, že v 90% prípadov sa polia a podmienky spojenia tabuliek zhodovali od požiadavky k požiadavke! Zdalo by sa, že každý SQL klient má funkcie automatického doplňovania, ale pre úložiská to nie vždy funguje: zriedka sa zavádzajú unique constraint a foreign key za účelom zvýšenia výkonu, a bez toho program nevie, ako sú entity navzájom prepojené a čo ti môže ponúknuť.
Po prechode cez popieranie, hnev, vyjednávanie, depresiu a blížiac sa k akceptácii, som sa rozhodol - prečo si to sám neskúsiť implementovať automatické doplňovanie s blackjackom a poriadne? Používam klienta dbeaver, napísaného v jave, má verziu komunity s otvoreným zdrojovým kódom. Vymyslel som jednoduchý plán:
- Nájsť v zdrojovom kóde triedy zodpovedajúce za automatické doplňovanie
- Preorientovať ich na prácu s externými metadátami a ťahať odtiaľ informácie o spojeniach
- ??????
- PROFIT
S prvým bodom som sa dosť rýchlo vyrovnal - našiel som v bugtrackeri požiadavku na opravu automatického doplňovania a v súvisiacom som objavil triedu SQLCompletionAnalyzer. Pozrel som sa na kód - presne to, čo potrebujem. Zostalo len prepísať ho tak, aby všetko fungovalo. Čakal som na voľný večer a začal premýšľať nad realizáciou. Pravidlá spojení tabuliek (metadáta) som sa rozhodol uchovávať v json. Nemal som praktické skúsenosti s týmto formátom a aktuálna úloha sa mi javila ako príležitosť tento nedostatok napraviť.
Na prácu s json som sa rozhodol použiť knižnicu od Googlu. Tu začali prekvapenia. Ako sa ukázalo, dbeaver, ako pravé aplikácie, je napísaný na platforme Eclipse s použitím OSGi rámca. Pre skúsených vývojárov táto vec poskytuje pohodlie správy závislostí, ale pre mňa vyzerala skôr ako čierna mágia, na ktorú som nebol vôbec pripravený: ako obvykle som uviedol import potrebných tried z knižnice json-simple na začiatku upravovanej triedy, uviedol ju do pom.xml, po čom projekt kategóricky odmietal normálne sa zostaviť a padal s chybami.
Opravenie chýb pri zostavovaní skončilo takto: knižnicu som zapísal nie do pom.xml, ale do manifestu manifest.mf, ako to vyžaduje OSGI, pričom som ju uviedol ako import-package. Nie je to najkrajšie riešenie, ale funguje. Tu sa objavil ďalší prekvapenie. Ak vyvíjate v intellij idea, nemôžete len tak spustiť ladenie svojho projektu založeného na platforme eclipse: nezkušený vývojár by mal trpieť rovnako, ako analytik bez automatického doplnenia dotazov. Na pomoc prišli sami vývojári bobra, ktorí uviedli na wiki všetky tance s bubnom, ktoré treba vykonať. Najviac mrzí, že aj po všetkých týchto presedávaniach sa projekt nechcel spustiť v ladení s pripojenou knižnicou json cez import-package (pritom, že v finálnom produkte sa aj naďalej úspešne zostavoval).
V tom čase som už cítil nekomfortnosť používania json pre moju úlohu – nakoniec, metadata sa plánovali upravovať ručne a na to formát xml lepšie vyhovuje. Druhým argumentom v prospech xml bolo, že v JDK sú všetky potrebné triedy, čo mi umožnilo prestať bojovať s externou knižnicou. S veľkým potešením som preniesol všetky metadata z json do xml a pustil sa do úprav logiky automatického doplnenia.
Príklad metadát
dim_account
dim_partner
dim_account
dim_branchV dôsledku toho som v triedach SQLUtils a SQLCompletionAnalyzer. Myšlienka je taká: ak sa programu nepodarí priradiť vhodné návrhy automatického doplnenia podľa základnej logiky, skontroluje prítomnosť možných spojení podľa externého súboru xml. V samotnom súbore sú uložené páry tabuliek so špecifikovanými poliami, podľa ktorých je potrebné tieto tabuľky prepojiť. Obmedzenia na technické dáta účinnosti záznamov eff_dttm a exp_dttm a prapor logického vymazania deleted_ind sa pritom nastavujú predvolene.
Keď boli do kódu zapracované úpravy, objavila sa otázka — kto naplní súbor s metadátami? V úložisku je veľa entít, ručne zapisovať všetky väzby by bolo náročné. Nakoniec som sa rozhodol zveriť túto úlohu svojim kolegom analytikom. Súbor metadát som zverejnil v svn, odkiaľ sa robí checkout do lokálneho adresára s programom. Princíp je taký: objavila sa v úložisku nová entita? Jeden analytik pridá možné joiny do súboru, commitne zmeny, ostatní si urobia checkout a užívajú si funkciu automatického vyplnenia: komunita, akumulácia vedomostí a tak ďalej. Urobil som workshop pre kolegov o používaní programu, napísal som článok do Confluence — teraz má spoločnosť jeden pohodlný nástroj navyše.
Práca na tejto funkcii mi dala pochopenie, že sa nemusíme báť skúmať open-source projekty — zvyčajne majú jasnú architektúru a na experimenty stačí aj základná znalosť jazyka. A s určitou dávkou vytrvalosti je možné zbaviť sa nenávidených rutinných operácií, čo ušetrí čas na nové experimenty.
Zdroj: habr.com
