Kas sa armastad rutiinseid toiminguid järjestikku kordama? Mina kindlasti mitte. Kuid iga kord, kui töötasin Rostelecomi andmebaasis SQL-kliendis, pidin kirjutama kõik tabelite ühendused käsitsi. Ja sellegipoolest, 90% juhtudest olid tabelite ühendamise väljad ja tingimused iga päringu puhul samad! Tundub, et igal SQL-kliendil on automaatse täitmise funktsioonid, kuid andmebaasides ei tööta see alati: seal on harva unikaalsed piirangud ja välisvõtmed tulemuslikkuse suurendamiseks, ning ilma nendeta ei tea programm, kuidas entiteedid omavahel seotud on ja mida ta sulle pakkuda saab.
Pärast eitamist, viha, kauplemist, depressiooni ja lähenemist aktsepteerimisele otsustasin — miks mitte proovida automatiseeritud täitmist mustade kaartide ja kõigi asjadega? Kasutan Java-s kirjutatud dbeaveri klienti, millel on avatud lähtekoodiga kogukonna versioon. Olin välja mõelnud lihtsa plaani:
- Leida avatud koodi klassid, mis vastutavad automaatse täitmise eest
- Suunata need töötama väliste metaandmete kallal ja tõmmata sealt ühenduste kohta teavet
- ??????
- PROFIT
Esimese punktiga sain piisavalt kiiresti hakkama — leidsin veaaruandest soovi automaatse täitmise kohandamiseks ja seotud avastasin klassi SQLCompletionAnalyzer. Vaatasin koodi — täpselt see, mida vajan. Jäi üle see ümber kirjutada, et kõik töötaks. Ootasin vaba õhtut ja hakkasin teostust läbi mõtlema. Tabelite seosereeglid (metaandmed) otsustasin viia json-formaadis. Mul ei olnud selle formaadi suhtes praktilisi kogemusi ja praegune ülesanne tundus võimalus selle puudujäägi parandamiseks.
JSON-i töötlemiseks otsustasin kasutada teeki Googlest. Siin hakkasid üllatused pihta. Kuidas selgus, on dbeaver, nagu tõeline rakendus, kirjutatud Eclipse'i platvormil kasutades OSGi raamistikku. Kogemustega arendajatele pakub see mugavust sõltuvuste haldamisel, ent minu jaoks näis see rohkem tumeda maagia sarnane, millega ma kindlasti ei olnud valmis tegelema: tavaliselt kirjutan vajalike klasside impordi json-simple teegist redigeeritava klassi pealkirja, määran selle pom.xml-is, kuid seejärel keeldub projekt normaalselt kogunemast ja kukub vigadega kokku.
Kohandmine ehitusvigu lõpuks selgus: ma registreerisin teegi mitte pom.xml-is, vaid manifest.mf-is, nagu nõuab OSGI, märkides selle import-package'ina. See pole kõige kaunim lahendus, aga töötab. Siin ilmus järgmine üllatus. Kui sa teed arendust intellij idea's, ei saa lihtsalt niisama võtta ja käivitada oma projekti häälestust, mis põhineb eclipse'i platvormil: kogenematu arendaja peab kannatama mitte vähem kui analüütik ilma automaatse päringu täiendamiseta. Appi tulid isegi bobri arendajad, kes on wikis välja toonud kõik nende tantsud, mida on vaja teha. Kõige kurvem on see, et isegi pärast kõiki neid hüppeid ei soovinud projekt käivituda häälestuses import-package kaudu laaditud json teegiga (kuigi valmis toode kogunes endiselt edukalt).
Sel hetkel olin juba tundnud ebamugavust json'i kasutamisest minu ülesande jaoks — lõpuks pidi metaandmeid käsitsi redigeerima, ja selleks sobib xml formaat paremini. Teiseks argumendiks xml kasuks oli vajalikud klassid, mis olid olemas JDK-s, mis võimaldas lõpetada välise teegi võitluse. Suure rõõmuga kolisin kõik metaandmed json'ist xml'i ja hakkasin autofill loogika redigeerimisega tegelema.
Metaandmete näide
dim_account
dim_partner
dim_account
dim_branchKokkuvõttes ma SQLUtils ja SQLCompletionAnalyzer klassidesse. Idee on järgmine: kui programm ei suutnud leida sobivaid autofill ettepanekuid aluselogi järgi, kontrollib see võimalike ühenduste olemasolu välises xml failis. Failis hoitakse tabelite paare koos välja nimedega, mille kaudu need tabelid tuleb seostada. Tehniliste kuupäevade piirangud registreerimise eff_dttm ja exp_dttm ning loogilise kustutamise flaga deleted_ind on seejuures vaikimisi seadistatud.
Kui koodimuudatused on tehtud, tekkis küsimus - kes hakkab täitma metadata faili? Andmehoidlas on palju objekte ja kõiki seoseid ise üles kirjutada on tülikas. Lõpuks otsustasin selle ülesande oma kolleegidele analüütikutele anda. Metaandmete faili panin svn-i, kust tehakse checkout kohalikku kausta programmiga. Põhimõte on selline: kui andmehoidlas tekib uus objekt? Üks analüütik lisab faili võimalikud seosed, kommitab muudatused, teised teevad checkout enda juurde ja naudivad töötavat automaatset täitmist: kogukond, teadmiste kogumine ja kõik selline. Kolleegidele tegin töötoa programmi kasutamiseks, kirjutasin artikli Confluence'i - nüüd on firmas üks mugavam tööriist rohkem.
Töö selle funktsiooni kallal andis mulle aru, et ei tasu karta avatud lähtekoodiga projektides nurgataguste kaevamist - tavaliselt on neil arusaadav arhitektuur ja isegi baaskeele teadmised on katsetamiseks piisavad. Ja teatud määral visadust kasutades saab lahti unustatud rutiinsetest operatsioonidest, säästes aega uute katsetuste jaoks.
Allikas: habr.com
