Cum să nu mai faci același lucru

Îți place să repeți operațiunile de rutină iar și iar? Deci nu. Dar de fiecare dată în clientul SQL când lucram cu stocarea Rostelecom, a trebuit să înregistrez manual toate îmbinările dintre tabele. Și asta în ciuda faptului că în 90% din cazuri câmpurile și condițiile pentru alăturarea tabelelor au coincis de la cerere la cerere! S-ar părea că orice client SQL are funcții de auto-completare, dar pentru stocări nu funcționează întotdeauna: rareori includ constrângeri unice și cheie străină pentru a îmbunătăți performanța, iar fără aceasta programul nu va ști cum sunt legate entitățile de fiecare. altele și ce poate face pentru dvs. oferă.

După ce am trecut prin negare, furie, târguire, depresie și apropierea acceptării, m-am hotărât - de ce să nu încerc să implementez eu însumi completarea automată cu blackjack și să o fac în mod corect? Folosesc clientul dbeaver, scris în java, are o versiune de comunitate open source. Un plan simplu s-a maturizat:

1. Găsiți clase în codul sursă care sunt responsabile pentru completarea automată
2. Redirecționați-i să lucreze cu metadate externe și să extragă informații despre alăturari de acolo
3. ??????
4. PROFIT

Mi-am dat seama destul de repede de primul punct - am găsit o solicitare în bug tracker pentru a ajusta completarea automată și în comite a descoperit clasa SQLCompletionAnalyzer. M-am uitat la cod și este ceea ce am nevoie. Tot ce rămâne este să-l rescrieți astfel încât totul să funcționeze. Am așteptat o seară liberă și am început să mă gândesc la implementare. Am decis să scriu regulile de link la tabel (metadate) în json. Nu aveam experiență practică de lucru cu acest format și sarcina actuală a fost văzută ca o oportunitate de a corecta această omisiune.

Pentru a lucra cu json, am decis să folosesc biblioteca json-simplu de la Google. De aici au început surprizele. După cum sa dovedit, dbeaver, ca o adevărată aplicație, a fost scris pe platforma Eclipse folosind cadrul OSGi. Pentru dezvoltatorii experimentați, acest lucru face să fie convenabil gestionarea dependențelor, dar pentru mine a fost mai degrabă ca o magie neagră, pentru care clar nu eram pregătit: ca de obicei, import clasele de care am nevoie din biblioteca json-simple din antetul clasa editată, specificați-o în pom xml, după care proiectul refuză categoric să se monteze în mod normal și se blochează cu erori.

În cele din urmă, am reușit să repar erorile de build: am înregistrat biblioteca nu în pom.xml, ci în manifestul manifest.mf, așa cum este cerut de OSGI, în timp ce l-am specificat ca import-package. Nu este cea mai frumoasă soluție, dar funcționează. Apoi a apărut următoarea surpriză. Dacă dezvoltați în Intellij Idea, nu puteți pur și simplu să începeți să vă depanați proiectul pe baza platformei Eclipse: un dezvoltator fără experiență ar trebui să sufere nu mai puțin decât un analist fără finalizarea interogării. Înșiși dezvoltatorii de castori au venit în ajutor, indicând în wiki toate dansurile cu tamburin care trebuie făcute. Cel mai enervant este că, chiar și după toate aceste squat-uri, proiectul nu a dorit să fie lansat în depanare cu biblioteca json conectată prin import-package (în ciuda faptului că a fost încă asamblat cu succes în produsul finit).

Până atunci, mi-am dat seama deja de inconvenientul utilizării json pentru sarcina mea - la urma urmei, metadatele trebuia să fie editate manual, iar formatul xml este mai potrivit pentru asta. Al doilea argument în favoarea xml a fost prezența tuturor claselor necesare în JDK, ceea ce a făcut posibilă oprirea luptei cu o bibliotecă externă. Cu mare plăcere, am transferat toate metadatele din json în xml și am început să editez logica de completare automată.

Exemplu de metadate

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

Ca urmare eu făcut modificări în clasele SQLUtils și SQLCompletionAnalyzer. Ideea este următoarea: dacă programul nu a reușit să găsească sugestii adecvate de completare automată folosind logica de bază, atunci verifică prezența posibilelor îmbinări folosind un fișier xml extern. Fișierul în sine stochează perechi de tabele care indică câmpurile prin care aceste tabele trebuie să fie legate. Restricțiile privind datele de valabilitate tehnică ale înregistrărilor eff_dttm și exp_dttm și marcajul de ștergere logică deleted_ind sunt setate implicit.

Când au fost făcute modificări la cod, a apărut întrebarea - cine va umple fișierul cu metadate? Există o mulțime de entități în depozit, este costisitor să înregistrați singur toate conexiunile. Ca urmare, am decis să atribui această sarcină colegilor mei analiști. Am postat fișierul de metadate în svn, de unde se face un checkout în directorul local cu programul. Principiul este acesta: a apărut o nouă entitate în depozit? Un analist introduce posibile asocieri în fișier, comite modificări, restul își verifică singuri și se bucură de auto-completarea de lucru: comunitate, acumulare de cunoștințe și toate astea. Am desfășurat un workshop despre utilizarea programului pentru colegi, a scris un articol în Confluence - acum compania are un instrument mai convenabil.

Lucrul la această caracteristică mi-a dat să înțeleg că nu trebuie să-mi fie frică să mă chinuiesc cu proiecte open source - de regulă, au o arhitectură clară și chiar și cunoștințele de bază ale limbajului vor fi suficiente pentru experimente. Și cu o anumită perseverență, vei putea chiar să scapi de operațiunile de rutină urate, economisindu-ți timp pentru noi experimente.

Sursa: www.habr.com