Ar jums patinka kartoti įprastas operacijas vėl ir vėl? Taigi aš ne. Bet kiekvieną kartą SQL kliente dirbdamas su „Rostelecom“ saugykla turėjau rankiniu būdu užregistruoti visus sujungimus tarp lentelių. Ir tai nepaisant to, kad 90% atvejų lentelių sujungimo laukai ir sąlygos sutapo nuo prašymo iki prašymo! Atrodytų, kad bet kuris SQL klientas turi automatinio užbaigimo funkcijas, tačiau saugyklose tai ne visada veikia: jie retai apima unikalų apribojimą ir išorinį raktą, kad pagerintų našumą, o be to programa nežinos, kaip objektai yra susiję su kiekvienu. kitas ir ką jis gali jums pasiūlyti.
Išgyvenęs neigimą, pyktį, derybas, depresiją ir artėjantį priėmimą, nusprendžiau – kodėl gi pačiam nepabandžius įgyvendinti automatinio užpildymo naudojant „blackjack“ ir nepadarius to teisingai? Aš naudoju dbeaver klientą, parašytą java, jis turi atvirojo kodo bendruomenės versiją. Subrendo paprastas planas:
- Šaltinio kode raskite klases, kurios yra atsakingos už automatinį užbaigimą
- Nukreipkite juos į darbą su išoriniais metaduomenimis ir iš ten gaukite informaciją apie prisijungimus
- ??
- PELNAS
Pirmą tašką supratau gana greitai - klaidų seklyje radau prašymą pakoreguoti automatinį pildymą ir susijusiame atrado SQLCompletionAnalyzer klasę. Pažiūrėjau kodą ir man jo reikia. Belieka perrašyti, kad viskas veiktų. Laukiau laisvo vakaro ir pradėjau galvoti apie įgyvendinimą. Nusprendžiau parašyti lentelės nuorodų taisykles (metaduomenis) JSON. Neturėjau praktinės patirties dirbant su šiuo formatu, o dabartinė užduotis buvo vertinama kaip galimybė ištaisyti šią trūkumą.
Norėdamas dirbti su json nusprendžiau naudoti biblioteką iš Google. Čia ir prasidėjo netikėtumai. Kaip paaiškėjo, dbeaver, kaip tikra programa, buvo parašyta Eclipse platformoje naudojant OSGi sistemą. Patyrusiems kūrėjams šis dalykas palengvina priklausomybių valdymą, tačiau man tai buvo labiau tamsi magija, kuriai aiškiai nebuvau pasiruošęs: kaip įprasta, importuoju man reikalingas klases iš json-simple bibliotekos antraštėje. redaguotą klasę, nurodykite ją pom xml, po kurios projektas kategoriškai atsisako normaliai surinkti ir sugenda su klaidomis.
Galiausiai pavyko ištaisyti kūrimo klaidas: biblioteką užregistravau ne pom.xml, o manifest.mf manifeste, kaip reikalauja OSGI, kartu nurodant kaip import-package. Ne pats gražiausias sprendimas, bet veikia. Tada pasirodė kita staigmena. Jei kuriate „Intellij Idea“, negalite tiesiog pradėti derinti savo projekto, pagrįsto „eclipse“ platforma: nepatyręs kūrėjas turėtų kentėti ne mažiau nei analitikas, neužbaigęs užklausos. Į pagalbą atskubėjo patys bebrų kūrėjai, kurie wikyje nurodė visus šokius su tamburinu, kuriuos reikia atlikti. Labiausiai erzina tai, kad net ir po visų šių pritūpimų projektas nenorėjo būti paleistas derinant su json biblioteka, prijungta per importo paketą (nepaisant to, kad ji vis tiek buvo sėkmingai surinkta į gatavą produktą).
Tuo metu jau supratau, kad json yra nepatogu naudoti savo užduočiai – juk metaduomenys turėjo būti redaguojami rankiniu būdu, o xml formatas tam labiau tinka. Antrasis argumentas xml naudai buvo visų būtinų klasių buvimas JDK, o tai leido sustabdyti kovą su išorine biblioteka. Su dideliu malonumu perkėliau visus metaduomenis iš json į xml ir pradėjau redaguoti automatinio užbaigimo logiką.
Metaduomenų pavyzdys
<?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>Dėl to I į SQLUtils ir SQLCompletionAnalyzer klases. Idėja tokia: jei programai nepavyko rasti tinkamų automatinio užbaigimo pasiūlymų, naudodama pagrindinę logiką, ji patikrina, ar nėra galimų sujungimų, naudodama išorinį xml failą. Pačiame faile saugomos lentelių poros, nurodančios laukus, pagal kuriuos šias lenteles reikia susieti. Įrašų eff_dttm ir exp_dttm techninių galiojimo datų ir loginio ištrynimo vėliavėlės deleted_ind apribojimai nustatyti pagal numatytuosius nustatymus.
Kai buvo atlikti kodo pakeitimai, iškilo klausimas – kas užpildys failą metaduomenimis? Saugykloje yra daug objektų, brangu visus ryšius registruoti patiems. Todėl nusprendžiau šią užduotį pavesti savo kolegoms analitikams. Įdėjau metaduomenų failą svn, iš kurio atliekama patikra į vietinį katalogą su programa. Principas toks: ar saugykloje atsirado naujas subjektas? Vienas analitikas įveda galimus prisijungimus į failą, atlieka pakeitimus, likusieji pasitikrina save ir mėgaujasi veikiančiu automatiniu užbaigimu: bendruomenė, žinių kaupimas ir visa kita. Surengė seminarą apie programos naudojimą kolegoms, parašė straipsnį „Confluence“ – dabar įmonė turi dar vieną patogesnį įrankį.
Dirbant su šia funkcija supratau, kad nereikia bijoti knaisiotis su atvirojo kodo projektais – kaip taisyklė, jie turi aiškią architektūrą, o eksperimentams užteks net elementarių kalbos žinių. Ir su tam tikru atkaklumu netgi galėsite atsikratyti nekenčiamų įprastų operacijų, sutaupydami laiko naujiems eksperimentams.
Šaltinis: www.habr.com