Si të ndaloni së bëri të njëjtën gjë

A ju pëlqen të përsërisni veprimet rutinë pa pushim? Kështu që unë nuk e bëj. Por çdo herë në klientin SQL kur punoja me ruajtjen e Rostelecom, më duhej të regjistroja manualisht të gjitha lidhjet midis tabelave. Dhe kjo pavarësisht se në 90% të rasteve fushat dhe kushtet për bashkimin e tabelave përkonin nga pyetësori në pyetje! Duket se çdo klient SQL ka funksione të plotësimit automatik, por për ruajtje nuk funksionon gjithmonë: ato rrallë përfshijnë kufizime unike dhe çelës të huaj për të përmirësuar performancën, dhe pa këtë programi nuk do të dijë se si lidhen entitetet me secilin të tjera dhe çfarë mund të bëjë për ju.

Pasi kalova mohimin, zemërimin, pazaret, depresionin dhe afrimin e pranimit, vendosa - pse të mos përpiqem të zbatoj vetë mbushjen automatike me blackjack dhe ta bëj atë në mënyrën e duhur? Unë përdor klientin dbeaver, të shkruar në java, ai ka një version të komunitetit me burim të hapur. Një plan i thjeshtë është pjekur:

1. Gjeni klasa në kodin burimor që janë përgjegjëse për plotësimin automatik
2. Ridrejtojini ata për të punuar me meta të dhënat e jashtme dhe nxirrni informacione rreth lidhjeve prej andej
3. ??
4. Fitimi

E kuptova shumë shpejt pikën e parë - gjeta një kërkesë në gjurmuesin e gabimeve për të rregulluar plotësimin automatik dhe në lidhjet përkatëse angazhohen zbuloi klasën SQLCompletionAnalyzer. Shikova kodin dhe është ajo që më duhet. E tëra që mbetet është ta rishkruajmë në mënyrë që gjithçka të funksionojë. Prita një mbrëmje të lirë dhe fillova të mendoj për zbatimin. Vendosa të shkruaj rregullat e lidhjes së tabelës (metadata) në json. Unë nuk kisha përvojë praktike duke punuar me këtë format dhe detyra aktuale u pa si një mundësi për të korrigjuar këtë lëshim.

Për të punuar me json vendosa të përdor bibliotekën json-i thjeshtë nga Google. Këtu filluan surprizat. Siç doli, dbeaver, si një aplikacion i vërtetë, u shkrua në platformën Eclipse duke përdorur kornizën OSGi. Për zhvilluesit me përvojë, kjo gjë e bën të përshtatshëm menaxhimin e varësive, por për mua ishte më shumë si magji e errët, për të cilën nuk isha qartësisht gati: si zakonisht, unë importoj klasat që më duhen nga biblioteka json-simple në kokën e klasën e redaktuar, specifikoni atë në pom.xml, pas së cilës projekti refuzon kategorikisht të montohet normalisht dhe rrëzohet me gabime.

Në fund, arrita të rregulloj gabimet e ndërtimit: e regjistrova bibliotekën jo në pom.xml, por në manifest.mf, siç kërkohet nga OSGI, ndërsa e specifikova si import-paketë. Nuk është zgjidhja më e bukur, por funksionon. Më pas u shfaq surpriza e radhës. Nëse po zhvilloni në Intellij Idea, nuk mund të shkoni dhe të filloni të korrigjoni projektin tuaj bazuar në platformën e eklipsit: një zhvillues i papërvojë duhet të vuajë jo më pak se një analist pa plotësimin e pyetjeve. Vetë zhvilluesit e kastorit erdhën në shpëtim, duke treguar në wiki të gjitha vallet me një dajre që duhen bërë. Gjëja më e bezdisshme është se edhe pas gjithë këtyre mbledhjeve, projekti nuk donte të lançohej në korrigjimin e gabimeve me bibliotekën json të lidhur përmes paketës së importit (pavarësisht faktit se ajo ishte ende e montuar me sukses në produktin e përfunduar).

Deri në atë kohë, unë e kisha kuptuar tashmë bezdinë e përdorimit të json për detyrën time - në fund të fundit, meta të dhënat supozohej të redaktoheshin manualisht, dhe formati xml është më i përshtatshëm për këtë. Argumenti i dytë në favor të xml ishte prania e të gjitha klasave të nevojshme në JDK, gjë që bëri të mundur ndalimin e luftimeve me një bibliotekë të jashtme. Me shumë kënaqësi, transferova të gjitha meta të dhënat nga json në xml dhe fillova të redaktoja logjikën e plotësimit automatik.

Shembull i meta të dhënave

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

Si rezultat, unë bërë ndryshime në klasat SQLUtils dhe SQLCompletionAnalyzer. Ideja është kjo: nëse programi nuk ishte në gjendje të gjente sugjerime të përshtatshme të plotësimit automatik duke përdorur logjikën bazë, atëherë ai kontrollon praninë e lidhjeve të mundshme duke përdorur një skedar të jashtëm xml. Vetë skedari ruan çifte tabelash që tregojnë fushat me të cilat këto tabela duhet të lidhen. Kufizimet në datat e vlefshmërisë teknike të regjistrimeve eff_dttm dhe exp_dttm dhe flamuri logjik i fshirjes deleted_ind janë vendosur si parazgjedhje.

Kur u bënë ndryshime në kod, lindi pyetja - kush do ta mbushë skedarin me meta të dhëna? Ka shumë entitete në depo, është e shtrenjtë të regjistrosh vetë të gjitha lidhjet. Si rezultat, vendosa t'ua caktoj këtë detyrë kolegëve të mi analistët. Unë postova skedarin e meta të dhënave në svn, nga ku bëhet një arkë në drejtorinë lokale me programin. Parimi është ky: a është shfaqur një ent i ri në depo? Një analist fut bashkimet e mundshme në dosje, kryen ndryshime, pjesa tjetër kontrollon veten dhe shijon përfundimin automatik të punës: komuniteti, akumulimi i njohurive dhe të gjitha këto. Kryen një punëtori për përdorimin e programit për kolegët, shkroi një artikull në Confluence - tani kompania ka një mjet më të përshtatshëm.

Puna në këtë veçori më dha të kuptuarit se nuk ka nevojë të kesh frikë të ndërhyj me projektet me burim të hapur - si rregull, ato kanë një arkitekturë të qartë, dhe madje edhe njohuritë themelore të gjuhës do të jenë të mjaftueshme për eksperimente. Dhe me një sasi të caktuar këmbënguljeje, madje do të jeni në gjendje të shpëtoni nga operacionet rutinë të urryera, duke i kursyer vetes kohë për eksperimente të reja.

Burimi: www.habr.com