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

A e ëmbëlsoni të përsërisni operacione rutinë nga një herë në tjetrën? Edhe unë jo. Por çdo herë në klientin SQL, kur punoja me depozitat e Rostelecom, më duhej të shkruaja dorazi të gjitha bashkimet midis tabelave. Dhe kjo, duke pasur parasysh se në 90% të rasteve fushat dhe kushtet e lidhjes së tabelave përputheshin nga pyetja në pyetje! Duke u parë, çdo klient SQL ka funksione automatik të plotësimit, por për depozitat nuk funksionon gjithmonë: rrallë ndodhin unikë të kufizimit dhe çeliku të huaj me qëllim për të rritur performancën, dhe pa këtë, programi nuk mund të dijë se si lidhen njësitë dhe çfarë mund të të propozojë.

Pas kalimit përmes mohimit, zemërimit, tregtisë, depresionit dhe duke i afruar pranimit, vendosa - pse të mos provoj të realizoj plotësim automat me blackjack dhe siç duhet? Unë përdor klientin dbeaver, i shkruar në java, i cili ka një version komuniteti me kod të hapur. Kisha një plan të thjeshtë:

1. Të gjej në kodin burimor klasat që janë përgjegjëse për plotësimin automat
2. T'i riorientoj për të punuar me metadëta të jashtme dhe të tërheq informacionin për bashkimet nga aty
3. ??????
4. PËRFITIM

Me pikën e parë u orientova mjaft shpejt - gjeta në ndihmën e gabimeve një kërkesë për rregullimin e plotësimit automat dhe në lidhjen e saj në komit e gjeta klasën SQLCompletionAnalyzer. E shihja kodin - ishte ashtu siç duhej. Mbeta për të shkruar atë që të gjitha të funksiononin. Prisja një mbrëmje të lirë dhe fillova të planifikoj realizimin. Rregullat e lidhjeve të tabelave (metadatë) vendosa t'i mbaj në json. Nuk kisha përvojë praktike në punën me këtë format dhe detyra aktuale dukej si një mundësi për të korrigjuar këtë mangësi.

Për të punuar me json vendosa të përdor librarinë json-simple nga gugl. Këtu filluan surprizat. Siç u zbulua, dbeaver, si një aplikacion të vërtetë, është shkruar në platformën e ekaliptit me përdorimin e kornizës OSGi. Për zhvilluesit e përvojshëm ky gjë ofron lehtësira në menaxhimin e varësive, për mua ndjehej si magji e errët, për të cilën nuk isha njëmend i gatshëm: si zakonisht e shkruaj importin e klasave që më nevojiten nga biblioteka json-simple në krye të klasës së redaktuar, e shënoj atë në pom.xml, pas së cilës projekti refuzon kategorikisht të ndërtohet normalisht dhe shpërbëhet me gabime.

Korrigjimi i gabimeve në ndërtim përfundimisht u realizua: e regjistrova bibliotekën jo në pom.xml, por në manifestin manifest.mf, siç kërkon OSGI, duke e treguar atë si import-package. Nuk është zgjidhje shumë e bukur, por funksionon. Këtu u shfaq një surprizë tjetër. Nëse je duke zhvilluar në intellij idea, nuk mund të marrësh thjesht dhe të nisësh debugin e projektit tënd, i bazuar në platformën eclipse: zhvilluesi i paekspozuar duhet të vuajë po aq sa analisti pa plotësimin automatik të kërkesave. Në ndihmë erdhën vetë zhvilluesit e bobrës, duke treguar në wiki të gjithë kërcimet që duhen bërë. Më e mërzitshmja është se, edhe pas të gjithë këtyre përpjekjeve, projekti nuk donte të niste në debug me bibliotekën json të lidhur përmes import-package (ndërsa, në produktin përfundimtar, ai vazhdonte të ndihmohej me sukses).

Në atë moment, unë kisha ndjerë shqetësimin e përdorimit të json për detyrën time - megjithatë, metadat duhet të redaktoheshin manualisht, dhe për këtë formatin xml është më i përshtatshëm. Argumenti i dytë në favor të xml ishte prania në JDK e të gjitha klasave të nevojshme, çka e lejoi ndalimin e luftës me bibliotekën e jashtme. Me kënaqësi të madhe, e transferova të gjitha metadat nga json në xml dhe fillova me ndryshimet në logjikën e plotësimit automatik.

Shembulli i metadatat

dim_account
        dim_partner
        
        
    
    
        dim_account
        dim_branch

Si rezultat unë bërë ndryshime në klasat SQLUtils dhe SQLCompletionAnalyzer. Ideja është kjo: nëse programit nuk i doli e mundur të gjejë propozonte të përshtatshme për plotësim automatik sipas logjikës bazë, atëherë kontrollon praninë e mundshëm të bashkimeve përmes një skedari xml të jashtëm. Në vetë skedarin ruhen çiftet e tabelave me përshkrimin e fushave që duhet të lidhin këto tabela. Kufizimet mbi datat teknike të veprimit të regjistrimeve eff_dttm dhe exp_dttm dhe flamuri i fshirjes logjike deleted_ind vendosen për default.

Kur të bëhen ndryshimet në kod, lind pyetja - kush do të plotësojë skedarin me metadata? Ka shumë entitete në depo, dhe të shkruash vetë të gjitha lidhjet është e shtrenjtë. Në fund vendosa ta delegoj këtë detyrë te kolegët e mi analistë. Skedari i metadata u ngarkua në svn, ku bëhet checkout në direktorinë lokale me programin. Parimi është i tillë: ndonjë entitet i ri u shfaq në depo? Një analist e shton mundësitë e bashkimeve në skedar, angazhon ndryshimet, të tjerët bëjnë checkout për vete dhe shijojnë autombushjen: komuniteti, grumbullimi i dijes dhe kështu me radhë. Mbajta një punëtor në lidhje me përdorimin e programit për kolegët, shkrova një artikull në Confluence - tani në kompani kemi një mjet të lehtë më shumë.

Puna mbi këtë veçori më dha kuptimin se nuk duhet të friksohemi nga përpunimi i projekteve open source - zakonisht, ato kanë një arkitekturë të kuptueshme, dhe madje njohuritë bazike të gjuhës do të mjaftojnë për eksperimente. Dhe me një masë të caktuar përkushtimi, madje do të arrish të eliminosh operacionet rutinë që nuk i don, duke kursyer kohë për eksperimente të reja.

Burimi: habr.com