🥇Cum să încetezi să faci același lucru

Îți place să repeți aceleași operații de fiecare dată? Mie nu. Dar de fiecare dată când lucram cu depozitul Rostelecom în clientul SQL, eram nevoit să specific manual toate join-urile între tabele. Și ținând cont că în 90% din cazuri câmpurile și condițiile de unire a tabelelor erau identice din interogare în interogare! Ar părea că orice client SQL are funcții de completare automată, dar pentru depozite nu funcționează întotdeauna: acolo rar sunt definite constraint-uri unice și chei externe pentru a îmbunătăți performanța, iar fără acestea programul nu poate înțelege cum sunt legate entitățile și ce îți poate oferi.

După ce am trecut prin negare, furie, negociere, depresie și apropiindu-mă de acceptare, m-am decis — de ce să nu încerc să implementez completarea automată cu blackjack și poate chiar mai bine? Folosesc clientul dbeaver, scris în java, care are o versiune comunitate cu sursă deschisă. Mi-a venit un plan simplu:

Să găsesc în codul sursă clasele responsabile pentru completarea automată
Să le redirecționez pentru a funcționa cu metadatele externe și să extrag informații despre join-uri de acolo
??????
PROFIT

Cu primul punct m-am descurcat destul de repede — am găsit în urma de bug-uri o cerere pentru corectarea completării automate și în legătura commit-ului am descoperit clasa SQLCompletionAnalyzer. Am aruncat o privire peste cod — exact ce aveam nevoie. Rămânea să-l rescriu astfel încât totul să funcționeze. Am așteptat o seară liberă și am început să mă gândesc la implementare. Regula legăturilor tabelelor (metadatele) am decis să le țin în json. Nu aveam experiență practică cu acest format și sarcina actuală mi s-a părut o oportunitate de a corecta această lipsă.

Pentru a lucra cu json am decis să folosesc biblioteca json-simple de la Google. Aici au început surprizele. Așa cum s-a dovedit, dbeaver, ca o aplicație adevărată, este scris pe platforma Eclipse folosind framework-ul OSGi. Pentru dezvoltatorii experimentați, acest lucru oferă confort în gestionarea dependențelor, dar pentru mine a fost mai mult ca magie neagră, la care evident nu eram pregătit: de obicei, specific importul claselor de care aveam nevoie din biblioteca json-simple în capul clasei editate, o indic în pom.xml, după care proiectul refuză categoric să se compileze corect și se prăbușește cu erori.

A corectat erorile de compilare, s-a realizat că biblioteca nu a fost specificată în pom.xml, ci în manifestul manifest.mf, așa cum cere OSGI, specificând-o ca import-package. Nu este cea mai elegantă soluție, dar funcționează. Aici a apărut următoarea surpriză. Dacă dezvolți în IntelliJ IDEA, nu poți pur și simplu să pornești debug-ul proiectului tău bazat pe platforma Eclipse: un dezvoltator neexperimentat trebuie să sufere la fel de mult ca un analist fără completarea automată a interogărilor. Au intervenit chiar dezvoltatorii bobrului, care au detaliat în wiki toate „dansurile cu tobă” care trebuiesc realizate. Cel mai frustrant este că, chiar și după toate aceste eforturi, proiectul nu dorea să pornească în debug cu biblioteca JSON conectată prin import-package (deși, în produsul final, el continua să se compileze cu succes).

Până la acel moment, am reușit să simt ineficiența utilizării JSON pentru sarcina mea — până la urmă, se presupunea că metadatele vor fi editate manual, iar formatul XML se potrivește mai bine. Un alt argument în favoarea XML a fost că JDK-ul conține toate clasele necesare, ceea ce a permis să pun capăt luptei cu biblioteca externă. Cu mare plăcere, am transferat toate metadatele din JSON în XML și am început să modific logica completării automate.

Exemplu de metadate

dim_account
        dim_partner
        
        
    
    
        dim_account
        dim_branch

În rezultat, am aduce modificări în clasele SQLUtils și SQLCompletionAnalyzer. Ideea este aceasta: dacă aplicația nu reușește să găsească sugestii adecvate pentru completarea automată conform logicii de bază, atunci verifică existența posibilelor join-uri în fișierul XML extern. În fișierul respectiv sunt stocate perechi de tabele cu specificarea câmpurilor care trebuie corelate. Restricțiile pentru datele tehnice de valabilitate ale înregistrărilor eff_dttm și exp_dttm, precum și indicatorul de ștergere logică deleted_ind sunt stabilite implicit.

După ce au fost făcute modificările în cod, a apărut întrebarea - cine va completa fișierul cu metadate? Există multe entități în depozit, așa că este dificil să scrii toate legăturile. În final, am decis să pun această sarcină pe umerii colegilor mei analizi. Am încărcat fișierul cu metadate în svn, de unde se face checkout în directorul local cu programul. Principiul este acesta: a apărut o nouă entitate în depozit? Un analist adaugă posibilele join-uri în fișier, comitează modificările, iar ceilalți fac checkout pentru ei și se bucură de completarea automată funcțională: comunitate, acumulare de cunoștințe și toate celelalte. Am organizat un workshop pentru colegi despre utilizarea programului, am scris un articol în Confluence - acum în companie avem un instrument convenabil în plus.

Lucrul la această caracteristică mi-a oferit înțelegerea faptului că nu trebuie să ne temem să explorăm proiectele open source - în general, au o arhitectură clară, iar cunoștințe de bază ale limbajului sunt suficiente pentru experimente. Și cu o dozare adecvată de perseverență, chiar poți scăpa de acele operațiuni rutiniere neplăcute, economisindu-ți timp pentru noi experimente.

Sursa: habr.com