Opakujete rádi rutinní operace znovu a znovu? Já tedy ne. Ale pokaždé, když jsem v SQL klientovi pracoval s úložištěm Rostelecom, musel jsem ručně zaregistrovat všechna spojení mezi tabulkami. A to přesto, že v 90 % případů se obory a podmínky pro spojování stolů shodovaly od požadavku k požadavku! Zdálo by se, že každý SQL klient má funkce automatického dokončování, ale u úložišť to vždy nefunguje: zřídka obsahují jedinečné omezení a cizí klíč, aby se zlepšil výkon, a bez toho program nebude vědět, jak entity souvisí s každým jiné a co pro vás může nabídnout.
Poté, co jsem prošel popíráním, hněvem, smlouváním, depresí a blížícím se přijetím, rozhodl jsem se – proč nezkusit zavést automatické vyplňování pomocí blackjacku sám a udělat to správným způsobem? Používám klienta dbeaver, napsaný v Javě, má open source komunitní verzi. Vyšel jednoduchý plán:
- Najděte ve zdrojovém kódu třídy, které jsou zodpovědné za automatické dokončování
- Přesměrujte je, aby pracovali s externími metadaty a odtud čerpali informace o spojeních
- ???
- ZISK
Na první bod jsem přišel celkem rychle – v bug trackeru jsem našel požadavek na úpravu automatického vyplňování a v souvisejícím objevil třídu SQLCompletionAnalyzer. Podíval jsem se na kód a je to, co potřebuji. Nezbývá než to přepsat, aby vše fungovalo. Počkal jsem na volný večer a začal promýšlet realizaci. Rozhodl jsem se napsat pravidla pro propojení tabulek (metadata) v json. Neměl jsem žádné praktické zkušenosti s prací s tímto formátem a aktuální úkol byl považován za příležitost toto opomenutí napravit.
Pro práci s json jsem se rozhodl použít knihovnu od Googlu. Tady začala překvapení. Jak se ukázalo, dbeaver jako skutečná aplikace byl napsán na platformě Eclipse s využitím frameworku OSGi. Pro zkušené vývojáře tato věc usnadňuje správu závislostí, ale pro mě to byla spíše temná magie, na kterou jsem zjevně nebyl připraven: jako obvykle importuji třídy, které potřebuji z knihovny json-simple v záhlaví upravenou třídu, uveďte ji v pom. xml, načež se projekt kategoricky odmítne sestavit normálně a zhroutí se s chybami.
Nakonec se mi podařilo opravit chyby sestavení: knihovnu jsem zaregistroval nikoli v pom.xml, ale v manifestu manifest.mf, jak požaduje OSGI, a uvedl jsem ji jako import-package. Není to nejhezčí řešení, ale funguje. Pak se objevilo další překvapení. Pokud vyvíjíte v Intellij Idea, nemůžete prostě jít a začít ladit svůj projekt založený na platformě Eclipse: nezkušený vývojář by neměl trpět méně než analytik bez dokončení dotazu. Sami vývojáři bobrů přišli na záchranu a na wiki uvedli všechny tance s tamburínou, které je třeba udělat. Nejnepříjemnější je, že ani po všech těch squatech se projekt nechtěl spustit v ladění s knihovnou json připojenou přes import-package (nehledě na to, že se to ještě podařilo zkompletovat do hotového produktu).
V té době jsem si již uvědomil nepříjemnost používání json pro můj úkol - metadata se přeci jen měla upravovat ručně a formát xml je pro to vhodnější. Druhým argumentem ve prospěch xml byla přítomnost všech potřebných tříd v JDK, což umožnilo přestat bojovat s externí knihovnou. S velkým potěšením jsem přenesl všechna metadata z json do xml a začal upravovat logiku automatického doplňování.
Příklad metadat
<?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 jsem do tříd SQLUtils a SQLCompletionAnalyzer. Myšlenka je následující: pokud program nebyl schopen najít vhodné návrhy automatického doplňování pomocí základní logiky, pak zkontroluje přítomnost možných spojení pomocí externího souboru xml. V samotném souboru jsou uloženy dvojice tabulek označující pole, kterými je třeba tyto tabulky propojit. Standardně jsou nastavena omezení pro data technické platnosti záznamů eff_dttm a exp_dttm a příznak logického smazání delete_ind.
Když byly provedeny změny v kódu, vyvstala otázka - kdo naplní soubor metadaty? V úložišti je mnoho subjektů, je drahé registrovat všechna připojení sami. V důsledku toho jsem se rozhodl svěřit tento úkol svým kolegům analytikům. Umístil jsem soubor metadat do svn, odkud se provádí kontrola do místního adresáře s programem. Princip je tento: objevila se v úložišti nová entita? Jeden analytik zadává možná spojení do souboru, zadává změny, zbytek se sám kontroluje a užívá si fungujícího automatického dokončování: komunita, shromažďování znalostí a tak dále. Uskutečnil workshop o používání programu pro kolegy, napsal článek do Confluence – nyní má společnost jeden pohodlnější nástroj.
Práce na této funkci mi dala pochopení, že není třeba se bát šťourat v open source projektech – ty mají zpravidla jasnou architekturu a na experimenty postačí i základní znalost jazyka. A s jistou dávkou vytrvalosti se dokonce budete moci zbavit nenáviděných rutinních operací, čímž si ušetříte čas na nové experimenty.
Zdroj: www.habr.com