Kako nehati delati isto

Radi znova in znova ponavljate rutinske operacije? Torej ne. Toda vsakič, ko sem delal s shrambo Rostelecom v odjemalcu SQL, sem moral ročno registrirati vse spoje med tabelami. In to kljub dejstvu, da so v 90% primerov polja in pogoji za združevanje tabel sovpadali od zahteve do zahteve! Zdi se, da ima vsak odjemalec SQL funkcije samodokončanja, vendar za shrambe to ne deluje vedno: le redko vključujejo edinstveno omejitev in tuji ključ, da bi izboljšali zmogljivost, brez tega pa program ne bo vedel, kako so entitete povezane z vsako drugo in kaj lahko stori za vašo ponudbo.

Potem ko sem šel skozi zanikanje, jezo, pogajanja, depresijo in približevanje sprejetju, sem se odločil - zakaj ne bi sam poskusil implementirati samodejno izpolnjevanje z blackjackom in to na pravi način? Uporabljam odjemalec dbeaver, napisan v Javi, ima odprtokodno različico skupnosti. Dozorel je preprost načrt:

1. Poiščite razrede v izvorni kodi, ki so odgovorni za samodejno dokončanje
2. Preusmerite jih k delu z zunanjimi metapodatki in od tam črpajte informacije o pridružitvah
3. ???
4. DOBIČEK

Prvo točko sem ugotovil precej hitro - v sledilniku hroščev sem našel zahtevo za prilagoditev samodejnega izpolnjevanja in v sorodnem zavezati odkril razred SQLCompletionAnalyzer. Pogledal sem kodo in to je tisto, kar potrebujem. Vse kar ostane je, da ga prepišemo tako, da vse deluje. Počakal sem na prost večer in začel razmišljati o izvedbi. Odločil sem se, da bom pravila povezav tabel (metapodatke) napisal v json. Nisem imel praktičnih izkušenj z delom s tem formatom in trenutno nalogo sem videl kot priložnost, da popravim to opustitev.

Za delo z json sem se odločil uporabiti knjižnico json-preprosto od Googla. Tu so se začela presenečenja. Kot se je izkazalo, je bil dbeaver kot prava aplikacija napisan na platformi Eclipse z uporabo ogrodja OSGi. Za izkušene razvijalce je ta stvar priročna za upravljanje odvisnosti, zame pa je bila bolj podobna temni magiji, na katero očitno nisem bil pripravljen: kot običajno uvozim razrede, ki jih potrebujem, iz knjižnice json-simple v glavi programa urejenega razreda, ga določite v pom.xml, po katerem se projekt kategorično noče normalno sestaviti in se zruši z napakami.

Na koncu mi je uspelo popraviti napake pri gradnji: knjižnice nisem registriral v pom.xml, ampak v manifestu manifest.mf, kot zahteva OSGI, medtem ko sem jo določil kot import-package. Ni najlepša rešitev, a deluje. Nato se je pojavilo naslednje presenečenje. Če razvijate v Intellij Idea, ne morete kar tako začeti odpravljati napak v svojem projektu, ki temelji na platformi eclipse: neizkušen razvijalec bi moral trpeti nič manj kot analitik brez dokončanja poizvedbe. Na pomoč so priskočili sami razvijalci bobra, ki so v wikiju navedli vse plese s tamburinom, ki jih je treba izvesti. Najbolj moteče je to, da se projekt tudi po vseh teh počepih ni hotel zagnati v debug z json knjižnico, povezano preko import-paketa (kljub temu, da je bil še vedno uspešno sestavljen v končni izdelek).

Do takrat sem že spoznal neprijetnost uporabe jsona za svojo nalogo - navsezadnje naj bi se metapodatki urejali ročno, format xml pa je za to bolj primeren. Drugi argument v prid xml je bila prisotnost vseh potrebnih razredov v JDK, kar je omogočilo prenehanje boja z zunanjo knjižnico. Z velikim veseljem sem prenesla vse metapodatke iz json v xml in se lotila urejanja autocomplete logike.

Primer metapodatkov

<?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>

Posledično sem naredil spremembe v razreda SQLUtils in SQLCompletionAnalyzer. Ideja je naslednja: če program ni mogel najti ustreznih predlogov za samodokončanje z uporabo osnovne logike, potem preveri prisotnost možnih združevanj z uporabo zunanje datoteke xml. Datoteka sama shranjuje pare tabel, ki označujejo polja, s katerimi je treba te tabele povezati. Omejitve glede datumov tehnične veljavnosti zapisov eff_dttm in exp_dttm ter zastavice za logično brisanje deleted_ind so privzeto nastavljene.

Ob spremembah kode se je pojavilo vprašanje - kdo bo datoteko zapolnil z metapodatki? V repozitoriju je veliko entitet, drago je, da sami registrirate vse povezave. Zato sem se odločil, da to nalogo zaupam kolegom analitikom. Datoteko z metapodatki sem objavil v svn, od koder se opravi prevzem v lokalni imenik s programom. Načelo je naslednje: ali se je v repozitoriju pojavila nova entiteta? En analitik vnese morebitne pridružitve v datoteko, potrdi spremembe, ostali preverijo sami in uživajo v delujočem samodokončanju: skupnost, kopičenje znanja in vse to. Izvedel delavnico o uporabi programa za sodelavce, napisal članek v Confluence - zdaj ima podjetje eno bolj priročno orodje.

Delo na tej funkciji mi je dalo razumevanje, da se ni treba bati poigravanja z odprtokodnimi projekti - praviloma imajo jasno arhitekturo in celo osnovno znanje jezika bo dovolj za poskuse. In z določeno mero vztrajnosti se boste lahko celo znebili osovraženih rutinskih operacij in si prihranili čas za nove poskuse.

Vir: www.habr.com