Máte rádi opakování rutinních operací? Já rozhodně ne. Ale pokaždé, když pracuji se skladem Rostelecom ve SQL klientovi, musím ručně psát všechny spojení mezi tabulkami. A to přitom v 90 % případů pole a podmínky spojení tabulek odpovídají od dotazu k dotazu! Mohlo by se zdát, že každý SQL klient má funkce automatického vyplňování, ale pro sklady to ne vždy funguje: málokdy se zavádí unikátní omezení a cizí klíč ve snaze o zvýšení výkonu, a bez toho program neví, jak jsou entity mezi sebou spojeny a co ti může nabídnout.
Po projití fází popírání, hněvu, vyjednávání, deprese a blížení se k přijetí jsem se rozhodl – proč si sám nevyzkoušet implementaci automatického vyplňování s blackjackem a na úrovni? Používám klienta dbeaver, který je napsán v Javě, má komunitní verzi s otevřeným zdrojovým kódem. Připravil jsem si jednoduchý plán:
- Najít ve zdrojovém kódu třídy odpovídající za automatické vyplňování
- Přeorientovat je na práci s externími metadaty a táhnout odtud informace o spojení
- ??????
- ZISK
S prvním bodem jsem si rychle poradil – našel jsem v bugtrackeru žádost o úpravu automatického vyplňování a ve spojení s jsem objevil třídu SQLCompletionAnalyzer. Podíval jsem se na kód – to, co potřebuji. Teď zbývalo jej přepsat tak, aby všechno fungovalo. Čekal jsem na volný večer a začal promýšlet realizaci. Pravidla vztahů tabulek (metadata) jsem se rozhodl vést v json. Neměl jsem praktické zkušenosti s tímto formátem a aktuální úkol se mi zdál být příležitostí to napravit.
Pro práci s json jsem se rozhodl použít knihovnu od Googlu. Tady začaly překvapení. Jak se ukázalo, dbeaver, jako skutečná aplikace, je napsán na platformě Eclipse s použitím OSGi frameworku. Pro zkušené vývojáře to nabízí pohodlné řízení závislostí, pro mě to však vypadalo spíše jako temná magie, na kterou jsem nebyl vůbec připraven: obvykle zapisuji import potřebných tříd z knihovny json-simple na začátku upravované třídy, uvedu ji v pom.xml, po čemž projekt zásadně odmítá normálně se sestavovat a padá s chybami.
Opravit chyby ve sestavení se podařilo: knihovna byla zapsána nikoli do pom.xml, ale do manifestu manifest.mf, jak vyžaduje OSGI, přičemž byla uvedena jako import-package. Není to nejhezčí řešení, ale funguje to. Pak přišlo další překvapení. Pokud vyvíjíte v IntelliJ IDEA, nemůžete jen tak spustit ladění svého projektu založeného na platformě Eclipse: nezkušený vývojář by měl trpět stejně, jako analytik bez automatického dokončování dotazů. Na pomoc přišli sami vývojáři Bobra, kteří v wiki uvedli všechny tance s bubnem, které je potřeba provést. Nejhorší je, že i po všech těchto útrapách se projekt nechtěl spouštět v ladění s připojenou knihovnou JSON pomocí import-package (přitom ve finálním produktu stále úspěšně kompiloval).
Do té doby jsem si stihl uvědomit nevýhody používání JSON pro svou úlohu — metadat bylo plánováno upravovat ručně, a pro toto je formát XML lepší. Druhým argumentem pro 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 se věnovat úpravám logiky automatického dokončování.
Příklad metadat
dim_account
dim_partner
dim_account
dim_branchV důsledku toho já v třídách SQLUtils a SQLCompletionAnalyzer. Myšlenka je taková: pokud se programu nepodařilo nalézt vhodné návrhy pro automatické dokončení na základě základní logiky, prověřuje, zda jsou možné spojení podle externího XML souboru. V samotném souboru jsou uloženy páry tabulek se specifikací polí, podle kterých je třeba tyto tabulky spojit. Omezení na technické datové datum platnosti záznamů eff_dttm a exp_dttm a flag logického smazání deleted_ind jsou přitom nastavena ve výchozím nastavení.
Když byly provedeny změny v kódu, objevila se otázka — kdo bude naplňovat soubor s metadatami? Ve skladu je mnoho entit, psaní všech vazeb by bylo náročné. Nakonec jsem se rozhodl svěřit tuto úlohu svým kolegům analytikům. Soubor metadat jsem umístil do svn, odkud se provádí checkout do lokálního adresáře s programem. Princip je takový: objevila se v úložišti nová entita? Jeden analytik vloží možné joiny do souboru, commituje změny, ostatní provedou checkout k sobě a užívají si funkční automatické vyplňování: komunita, akumulace znalostí a tak dále. Uskutečnil jsem pro kolegy workshop o používání programu, napsal jsem článek do Confluence — nyní má firma jeden pohodlný nástroj navíc.
Práce na této funkci mi dala pochopení, že se nemusím bát hrabat se v open-source projektech — obvykle mají jasnou architekturu, a i základní znalosti jazyka budou stačit k experimentování. A s určitou dávkou vytrvalosti se dokonce podaří zbavit se nenáviděných rutinních operací, čímž si ušetříte čas na nové pokusy.
Zdroj: habr.com
