Kako prestati raditi istu stvar

Volite li uvijek iznova ponavljati rutinske operacije? Tako da ne znam. Ali svaki put u SQL klijentu kada sam radio s pohranom Rostelecoma, morao sam ručno registrirati sve spojeve između tablica. I to unatoč činjenici da su se u 90% slučajeva polja i uvjeti za spajanje tablica podudarali od upita do upita! Čini se da svaki SQL klijent ima funkcije automatskog dovršavanja, ali za pohrane to ne radi uvijek: oni rijetko uključuju jedinstveno ograničenje i strani ključ kako bi se poboljšala izvedba, a bez toga program neće znati kako su entiteti povezani sa svakim drugo i što može učiniti za vašu ponudu.

Nakon što sam prošao kroz poricanje, ljutnju, pregovaranje, depresiju i približavanje prihvaćanju, odlučio sam - zašto ne bih sam pokušao implementirati autofill s blackjackom i to na pravi način? Koristim dbeaver klijent, napisan u Javi, ima open source verziju zajednice. Sazreo je jednostavan plan:

1. Pronađite klase u izvornom kodu koje su odgovorne za automatsko dovršavanje
2. Preusmjerite ih da rade s vanjskim metapodacima i odande povlače informacije o pridruživanjima
3. ??????
4. DOBIT

Prvu sam točku shvatio prilično brzo - pronašao sam zahtjev u alatu za praćenje bugova za podešavanje automatskog popunjavanja i u povezanom počiniti otkrio klasu SQLCompletionAnalyzer. Pogledao sam kod i to je ono što mi treba. Ostaje samo prepisati ga tako da sve radi. Pričekao sam slobodnu večer i počeo razmišljati o provedbi. Odlučio sam napisati pravila povezivanja tablice (metapodatke) u jsonu. Nisam imao praktičnog iskustva u radu s ovim formatom i trenutni zadatak smatrao sam prilikom da ispravim ovaj propust.

Za rad s jsonom odlučio sam koristiti biblioteku json-jednostavan od Googlea. Tu su počela iznenađenja. Kako se pokazalo, dbeaver je kao prava aplikacija napisan na Eclipse platformi koristeći OSGi framework. Za iskusne programere ova stvar olakšava upravljanje ovisnostima, ali za mene je to više nalikovalo mračnoj magiji, za koju očito nisam bio spreman: kao i obično, uvozim klase koje su mi potrebne iz json-simple biblioteke u zaglavlju uređenu klasu, specificirajte je u pom.xml, nakon čega se projekt kategorički odbija normalno sastaviti i ruši s pogreškama.

Na kraju sam uspio ispraviti greške u izradi: registrirao sam biblioteku ne u pom.xml, već u manifest.mf manifest, kako zahtijeva OSGI, dok sam je specificirao kao import-package. Nije najljepše rješenje, ali djeluje. Tada se pojavilo sljedeće iznenađenje. Ako razvijate u Intellij Idea, ne možete samo otići i početi ispravljati pogreške u svom projektu na temelju platforme eclipse: neiskusni programer trebao bi patiti ništa manje od analitičara bez dovršetka upita. Programeri dabra sami su priskočili u pomoć, navodeći u wikiju sve plesove s tamburinom koje je potrebno izvesti. Najviše je smetalo što se projekt ni nakon svih ovih čučnjeva nije htio pokrenuti u debugu s json bibliotekom spojenom preko import-paketa (unatoč tome što je ipak uspješno montiran u gotov proizvod).

Do tada sam već shvatio koliko je neugodno koristiti json za svoj zadatak - na kraju krajeva, metapodatke je trebalo uređivati ​​ručno, a xml format je za to prikladniji. Drugi argument u korist xml-a bila je prisutnost svih potrebnih klasa u JDK-u, što je omogućilo prestanak borbe s vanjskom bibliotekom. S velikim sam zadovoljstvom prebacio sve metapodatke iz jsona u xml i počeo uređivati ​​autocomplete logiku.

Primjer metapodataka

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

Kao rezultat toga ja napravio promjene u klase SQLUtils i SQLCompletionAnalyzer. Ideja je sljedeća: ako program nije mogao pronaći odgovarajuće prijedloge za automatsko dovršavanje pomoću osnovne logike, tada provjerava prisutnost mogućih spajanja pomoću vanjske xml datoteke. Sama datoteka pohranjuje parove tablica koje označavaju polja kojima te tablice trebaju biti povezane. Ograničenja tehničkih datuma valjanosti zapisa eff_dttm i exp_dttm i logička oznaka brisanja deleted_ind postavljena su prema zadanim postavkama.

Kada su napravljene izmjene koda, postavilo se pitanje - tko će popuniti datoteku metapodacima? U repozitoriju ima puno entiteta, skupo je sami registrirati sve veze. Kao rezultat toga, odlučio sam taj zadatak dodijeliti svojim kolegama analitičarima. Objavio sam datoteku metapodataka u svn, odakle se vrši odjava u lokalni direktorij s programom. Princip je sljedeći: je li se novi entitet pojavio u repozitoriju? Jedan analitičar unosi moguća pridruživanja u datoteku, upisuje promjene, ostali se odjavljuju sami i uživaju u radnom automatskom dovršavanju: zajednica, akumulacija znanja i sve to. Proveo radionicu o korištenju programa za kolege, napisao članak u Confluenceu - sada tvrtka ima još jedan praktičniji alat.

Rad na ovoj značajci dao mi je razumijevanje da se ne treba bojati petljati s projektima otvorenog koda - u pravilu imaju jasnu arhitekturu, a čak i osnovno poznavanje jezika bit će dovoljno za eksperimente. A uz određenu dozu upornosti, moći ćete se čak i riješiti omraženih rutinskih operacija, štedeći si vrijeme za nove eksperimente.

Izvor: www.habr.com