Kuidas lõpetada sama asja tegemine

Kas teile meeldib rutiinseid toiminguid ikka ja jälle korrata? Nii et ma ei tee seda. Kuid iga kord, kui SQL-kliendis Rostelecomi salvestusruumiga töötades, pidin kõik tabelitevahelised ühendused käsitsi registreerima. Ja seda hoolimata asjaolust, et 90% juhtudest langesid laudade ühendamise väljad ja tingimused soovist soovini! Näib, et igal SQL-kliendil on automaatse täitmise funktsioonid, kuid salvestusruumide puhul see alati ei tööta: need sisaldavad jõudluse parandamiseks harva ainulaadset piirangut ja võõrvõtit ning ilma selleta ei tea programm, kuidas üksused on omavahel seotud. muud ja mida see teile pakkuda saab.

Olles läbi elanud eitamise, viha, läbirääkimisi, depressiooni ja lähenevat aktsepteerimist, otsustasin – miks mitte proovida ise blackjackiga automaattäitmist rakendada ja teha seda õigesti? Ma kasutan dbeaveri klienti, mis on kirjutatud java keeles, sellel on avatud lähtekoodiga kogukonna versioon. Lihtne plaan on küpsenud:

1. Leidke lähtekoodist klassid, mis vastutavad automaatse täitmise eest
2. Suunake need ümber väliste metaandmetega töötama ja hankige sealt teavet liitumiste kohta
3. ??????
4. KASUM

Esimese punkti sain üsna kiiresti selgeks - leidsin veajälgijast palve automaatse täitmise reguleerimiseks ja sellega seotud pühenduma avastas klassi SQLCompletionAnalyzer. Vaatasin koodi ja see on see, mida ma vajan. Jääb vaid see ümber kirjutada, et kõik toimiks. Ootasin vaba õhtut ja hakkasin teostust läbi mõtlema. Otsustasin kirjutada tabeli linkide reeglid (metaandmed) json-vormingus. Mul puudus selle formaadiga töötamise praktiline kogemus ja praegust ülesannet nähti võimalusena seda puudujääki parandada.

Jsoniga töötamiseks otsustasin kasutada raamatukogu json-lihtne Google'ilt. Siit algasid üllatused. Nagu selgus, kirjutati dbeaver kui tõeline rakendus Eclipse'i platvormile, kasutades OSGi raamistikku. Kogenud arendajatele teeb see asi sõltuvuste haldamise mugavaks, kuid minu jaoks oli see pigem tume maagia, milleks ma ilmselgelt valmis polnud: nagu tavaliselt, impordin vajalikud klassid json-simple teegist päises. redigeeritud klass, täpsustage see pom.xml-s, misjärel projekt keeldub kategooriliselt tavapärasest kokkupanemisest ja jookseb vigadega kokku.

Lõpuks õnnestus mul koostamisvead parandada: registreerisin raamatukogu mitte pom.xml-s, vaid manifest.mf manifestis, nagu OSGI nõuab, määrates seejuures importpaketiks. Pole just kõige ilusam lahendus, aga toimib. Siis ilmus järgmine üllatus. Kui arendate Intellij Ideas, ei saa te lihtsalt minna ja alustada oma projekti silumist eclipse'i platvormi alusel: kogenematu arendaja peaks ilma päringu lõpetamata kannatama vähem kui analüütik. Appi tulid kopraarendajad ise, kes märkisid vikis kõik parmupilliga tantsud, mis tuleb teha. Kõige tüütum on see, et isegi pärast kõiki neid kükitamist ei tahtnud projekt käivitada silumisel import-paketi kaudu ühendatud jsoni teegiga (hoolimata sellest, et see ikkagi edukalt valmistooteks kokku monteeriti).

Selleks ajaks olin juba mõistnud jsoni kasutamise ebamugavust oma ülesande täitmisel - metaandmeid pidi ju käsitsi redigeerima ja xml-vorming sobib selleks paremini. Teine argument xml-i kasuks oli kõigi vajalike klasside olemasolu JDK-s, mis võimaldas välise teegiga võitlemise lõpetada. Suure rõõmuga kandsin kõik metaandmed jsonist xml-i ja hakkasin automaatse täitmise loogikat redigeerima.

Metaandmete näide

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

Selle tulemusena I teinud muudatusi klassidesse SQLUtils ja SQLCompletionAnalyzer. Idee on järgmine: kui programm ei leidnud põhiloogikat kasutades sobivaid automaatse täitmise soovitusi, kontrollib see välise xml-faili abil võimalike liitumiste olemasolu. Fail ise salvestab tabelipaare, mis näitavad väljad, mille abil need tabelid tuleb siduda. Kirjete eff_dttm ja exp_dttm tehniliste kehtivuskuupäevade piirangud ning loogilise kustutamise lipp deleted_ind on vaikimisi seatud.

Kui koodis muudatusi tehti, tekkis küsimus – kes täidab faili metaandmetega? Hoidlas on palju üksusi, kõigi ühenduste ise registreerimine on kallis. Seetõttu otsustasin anda selle ülesande oma kolleegidele analüütikutele. Panin üles metaandmete faili svn-s, kust tehakse kassasse programmiga kohalikku kataloogi. Põhimõte on järgmine: kas hoidlasse on ilmunud uus olem? Üks analüütik sisestab faili võimalikud liitumised, teeb muudatused, ülejäänud kontrollivad ise ja naudivad töötavat automaatset lõpetamist: kogukonda, teadmiste kogumist ja kõike muud. Viinud kolleegidele läbi töötoa programmi kasutamise kohta, kirjutanud artikli Confluence'is - nüüd on ettevõttel üks mugavam tööriist.

Selle funktsiooni kallal töötamine andis mulle arusaama, et avatud lähtekoodiga projektide kallal nokitsemist pole vaja karta - reeglina on neil selge arhitektuur ja katseteks piisab isegi elementaarsetest keeleteadmistest. Ja teatud järjekindlusega saate isegi vihatud rutiinsetest operatsioonidest lahti, säästes aega uuteks katseteks.

Allikas: www.habr.com