Radi opakujete rutinné operácie znova a znova? Ja teda nie. Ale zakaždým, keď som v klientovi SQL pracoval s úložiskom Rostelecom, musel som manuálne zaregistrovať všetky spojenia medzi tabuľkami. A to aj napriek tomu, že v 90% prípadov sa polia a podmienky spájania tabuliek zhodovali od dotazu k dotazu! Zdá sa, že každý SQL klient má funkcie automatického dopĺňania, ale pre úložiská to nie vždy funguje: zriedka obsahujú jedinečné obmedzenie a cudzí kľúč, aby sa zlepšil výkon, a bez toho program nebude vedieť, ako súvisia entity s každým iné a čo vám môže ponúknuť.
Keď som prešiel popieraním, hnevom, vyjednávaním, depresiou a blížiacim sa prijatím, rozhodol som sa – prečo neskúsiť implementovať automatické dopĺňanie pomocou blackjacku sám a urobiť to správnym spôsobom? Používam klienta dbeaver, napísaný v jazyku Java, má open source komunitnú verziu. Dozrel jednoduchý plán:
- Nájdite v zdrojovom kóde triedy, ktoré sú zodpovedné za automatické dopĺňanie
- Presmerujte ich, aby pracovali s externými metaúdajmi a odtiaľ získavali informácie o spojeniach
- ???
- PROFIT
Na prvý bod som prišiel pomerne rýchlo – v nástroji na sledovanie chýb som našiel požiadavku na úpravu automatického dopĺňania a v súvisiacich objavil triedu SQLCompletionAnalyzer. Pozrel som sa na kód a je to, čo potrebujem. Zostáva to už len prepísať, aby všetko fungovalo. Počkal som na voľný večer a začal premýšľať nad realizáciou. Rozhodol som sa napísať pravidlá prepojenia tabuľky (metadáta) v json. Nemal som žiadne praktické skúsenosti s prácou s týmto formátom a súčasná úloha bola vnímaná ako príležitosť na nápravu tohto opomenutia.
Na prácu s json som sa rozhodol použiť knižnicu od spoločnosti Google. Tu sa začali prekvapenia. Ako sa ukázalo, dbeaver, ako skutočná aplikácia, bol napísaný na platforme Eclipse pomocou rámca OSGi. Pre skúsených vývojárov táto vec uľahčuje správu závislostí, ale pre mňa to bola skôr temná mágia, na ktorú som zjavne nebol pripravený: ako obvykle importujem triedy, ktoré potrebujem z knižnice json-simple v hlavičke upravenú triedu, špecifikujte ju v pom.xml, po čom sa projekt kategoricky odmietne zostaviť normálne a havaruje s chybami.
Nakoniec sa mi podarilo opraviť chyby zostavy: Knižnicu som zaregistroval nie v pom.xml, ale v manifest.mf manifest, ako to vyžaduje OSGI, pričom som ju špecifikoval ako import-package. Nie je to najkrajšie riešenie, ale funguje. Potom sa objavilo ďalšie prekvapenie. Ak vyvíjate v Intellij Idea, nemôžete jednoducho ísť a začať ladiť svoj projekt založený na platforme Eclipse: neskúsený vývojár by nemal trpieť o nič menej ako analytik bez dokončenia dotazu. Samotní vývojári bobrov prišli na záchranu a na wiki uviedli všetky tance s tamburínou, ktoré je potrebné urobiť. Najnepríjemnejšie na tom je, že ani po všetkých týchto squatoch sa projekt nechcel spustiť v ladení s knižnicou json pripojenou cez import-package (napriek tomu, že bol ešte úspešne zostavený do hotového produktu).
V tom čase som si už uvedomil nepríjemnosť používania json pre moju úlohu - koniec koncov, metadáta sa mali upravovať ručne a formát xml je na to vhodnejší. Druhým argumentom v prospech xml bola prítomnosť všetkých potrebných tried v JDK, čo umožnilo prestať bojovať s externou knižnicou. S veľkým potešením som preniesol všetky metadáta z json do xml a začal upravovať logiku automatického dopĺňania.
Príklad metadát
<?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>V dôsledku toho som do tried SQLUtils a SQLCompletionAnalyzer. Myšlienka je takáto: ak program nedokázal nájsť vhodné návrhy automatického dopĺňania pomocou základnej logiky, potom skontroluje prítomnosť možných spojení pomocou externého súboru xml. V samotnom súbore sú uložené dvojice tabuliek označujúce polia, pomocou ktorých je potrebné tieto tabuľky prepojiť. Štandardne sú nastavené obmedzenia týkajúce sa dátumov technickej platnosti záznamov eff_dttm a exp_dttm a príznak logického vymazania delete_ind.
Keď boli vykonané zmeny v kóde, vyvstala otázka - kto naplní súbor metadátami? V úložisku je veľa subjektov, je drahé zaregistrovať všetky pripojenia sami. V dôsledku toho som sa rozhodol prideliť túto úlohu svojim kolegom analytikom. Súbor s metadátami som zaúčtoval do svn, odkiaľ sa vykoná kontrola do lokálneho adresára s programom. Princíp je takýto: objavila sa v úložisku nová entita? Jeden analytik zadá možné spojenia do súboru, vykoná zmeny, zvyšok sa sám skontroluje a užíva si pracovné automatické dopĺňanie: komunita, hromadenie vedomostí a tak ďalej. Uskutočnil workshop o používaní programu pre kolegov, napísal článok do Confluence – teraz má spoločnosť jeden pohodlnejší nástroj.
Práca na tejto funkcii mi dala pochopenie, že sa netreba báť vŕtať v open source projektoch - spravidla majú jasnú architektúru a na experimenty postačia aj základné znalosti jazyka. A s určitou dávkou vytrvalosti sa dokonca budete môcť zbaviť nenávidených rutinných operácií, čím si ušetríte čas na nové experimenty.
Zdroj: hab.com