Kas sa armastad pidevalt rutiinseid toiminguid korrata? Mina mitte. Kuid iga kord, kui töötasin Rostelecomi andmebaasiga SQL-kliendiga, pidin ma käsitsi kirjutama kõik tabelite liitmisoperatsioonid. Ja see vaatamata sellele, et 90% juhtudel olid väljad ja liitmistingimused samad igas päringus! Tundub, et iga SQL-kliendi puhul on auto täitmise funktsioon olemas, kuid andmebaaside puhul see alati ei tööta: nendes harva kasutatakse unikaalseid constraint'e ja välisvõtmeid jõudluse tõstmiseks, ilma milleta programm ei tea, kuidas olendid omavahel seotud on ja mida ta sulle pakkuda saab.
Pärast eitamise, viha, kauplemise, masenduse läbimist ja aktsepteerimise lähenemist otsustasin — miks mitte proovida ise autotäidet luua blackjacki ja korralikult? Kasutan dbeaveri klienti, mis on kirjutatud java keeles, sellel on avatud koodiga kogukonna versioon. Kokku küpsenud plaan:
- Leida lähtekoodis klassid, mis vastutavad auto täitmise eest
- Taas suunata need töötama välistest metaandmetest ja tuua sealt teavet liitumiste kohta
- ??????
- PROFIT
Esimese punktiga sain kiiresti hakkama — leidsin veahaldusest sisendi automaatse täitmise parendamiseks ja seotud leiutati SQLCompletionAnalyzer klass. Vaatasin koodi — just niinagu vaja. Jäänud oli see ümber kirjutada nii, et kõik toimiks. Oodates vabakutset õhtul, hakkasin ellu viima plaani. Otsustasin, et salvestan tabelite seosereeglid (metainformatsiooni) json-formaadis. Mul ei olnud praktilist kogemust selle formaadiga ning hetkeülesanne tundus võimalus seda puudujääki täita.
Jsoniga töötamiseks otsustasin kasutada Google'ilt. Siit hakkasid üllatused. Selgus, et dbeaver, tõeliselt rakendus, on kirjutatud Eclipse platvormil OSGi raamistikuga. Kogenud arendajatele toob see mugavuse sõltuvuste haldamisel, kuid mulle oli see pigem nagu must maagia, milleks ma ei olnud ilmselgelt valmis: nagu alati, kirjutasin importi vajalikke klasse json-simple'ist redigeeritava klassi pealkirjas, märkisin selle pom.xml failis, pärast mida projekt kategooriliselt keeldus normaalselt kokkutoomast ja kukkus vigadega.
Kompileerimisvead said lahendatud: teisinga teegi ei lisatud pom.xml faili, vaid manifeesti manifest.mf, nagu OSGI nõuab, märkides selle import-package'ina. Ei ole kõige elegantsem lahendus, kuid töötab. Siis tuli järgmine üllatus. Kui te arendate IntelliJ IDEA's, ei saa te lihtsalt nii võtta ja käivitada oma projekti silumist, mis põhineb Eclipse'i platvormil: kogenematu arendaja peab kannatama sama palju, kui analüütik, kellel pole automaatset täiendamist. Appi tulid arendajad ise, kes tõid wiki's välja kõik tantsud, mis tuleb läbi viia. Kõige rohkem häirib see, et isegi pärast kõiki neid pingutusi ei soovinud projekt käivituda silumisrežiimis, koos import-package'iga ühendatud JSON teegiga (kuigi valmistoode kompileerus endiselt edukalt).
Selle ajaks olin juba kogenud JSON-i kasutamise ebamugavust oma ülesande jaoks — lõppude lõpuks pidi metaandmeid käsitsi redigeerima ja selleks sobib XML formaat paremini. Teiseks argumendiks XML-i kasuks oli JDK-s olemasolevate vajalike klasside hulk, mis andis võimaluse lõpetada võitlus välise teegiga. Suure heameelega tõin kõik metaandmed JSON-ist XML-i ja alustasin automaatse täitmise loogika muutmist.
Metaandmete näide
dim_account
dim_partner
dim_account
dim_branchTulemuseks oli, et ma klassides SQLUtils ja SQLCompletionAnalyzer. Idee on järgmine: kui programm ei suuda põhiloogika kohaselt leida sobivaid automaatse täitmise ettepanekuid, kontrollib ta, kas välistest XML-failidest on võimalik liitumisi. Failis hoitakse tabelite paare, märkides, milliste väljade järgi neid tabeleid siduda. Kande tehniliste kehtivuse kuupäevade eff_dttm ja exp_dttm piirangud ning loogilise kustutamise lipp deleted_ind määratakse vaikimisi.
Kui koodis muudatused tehti, tuli küsimus — kes täidab metaandmete faili? Kataloogis on palju süstemaatilisi üksusi ja nende kõigi sidumine on vaevanõudev. Lõpuks otsustasin selle ülesande anda oma kolleegidele-analüütikutele. Metaandmete faili panin svn-i, kust see tõmmatakse kohalikku kataloogi programmiga. Prinsip on järgmine: kui kataloogis on uus üksus? Üks analüütik lisab faili võimalikke ühendusi, paneb muudatused toime, teised tõmbavad endale ja naudivad töötavat automaatset täitmist: kogukond, teadmiste kogumine ja kõik muud head asjad. Viisin kolleegidele läbi töötuba programmi kasutamisest, kirjutasin artikli Confluence'i — nüüd on ettevõttes veel üks mugav tööriist olemas.
Töö selle funktsiooni kallal andis mulle arusaama, et ei tasu karta avatud allika projekte — üldiselt on nende arhitektuur arusaadav ja isegi põhiteadmised keelest on katsetamiseks piisavad. Ja teatud sihikindluses suudab isegi vabaneda vihatud rutiinsetest operatsioonidest, säästes end aega uute katsetuste jaoks.
Allikas: habr.com
