Cumu piantà di fà a listessa cosa

Ti piace à ripetiri l'operazioni di rutina una volta è più? Allora ùn aghju micca. Ma ogni volta in u cliente SQL quandu u travagliu cù l'almacenamiento Rostelecom, aghju avutu à registrà tutte e unione trà e tavule manualmente. E questu malgradu u fattu chì in u 90% di i casi i campi è e cundizioni per unisce e tavule coincidevanu da una dumanda à una dumanda! Sembra chì ogni cliente SQL hà funzioni di cumpletu automaticu, ma per i magazzini ùn funziona micca sempre: raramente includenu limitazione unica è chjave straniera per migliurà u rendiment, è senza questu u prugramma ùn sapi micca cumu l'entità sò ligati à ognunu. altru è ciò chì pò fà per voi offre.

Dopu avè passatu a negazione, a rabbia, a negoziazione, a depressione è l'avvicinamentu di l'accettazione, aghju decisu - perchè ùn pruvate micca di implementà l'autofill cù u blackjack per mè stessu è fà u modu ghjustu? Aduprà u cliente dbeaver, scrittu in java, hà una versione di a cumunità open source. Un pianu simplice hè maturatu:

1. Truvate classi in u codice fonte chì sò rispunsevuli di l'autocompletion
2. Redirect elli à travaglià cù metadati esterni è tirà infurmazione nantu à unisce da quì
3. ??????
4. PROFIT

Aghju capitu u primu puntu abbastanza rapidamente - aghju trovu una dumanda in u bug tracker per aghjustà l'autofill è in i correlati impegnà scupertu a classa SQLCompletionAnalyzer. Aghju guardatu u codice è hè ciò chì aghju bisognu. Il ne reste plus qu'à récrire pour que tout fonctionne. Aghju aspittatu per una sera libera è cuminciaru à pensà à l'implementazione. Aghju decisu di scrive e regule di ligame di tabella (metadata) in json. Ùn aghju avutu micca una sperienza pratica di travaglià cù stu formatu è u travagliu attuale hè statu vistu cum'è una opportunità per correggerà sta omissione.

Per travaglià cù json, aghju decisu di utilizà a biblioteca json-semplice da Google. Hè quì chì e sorprese cumincianu. Cum'è hè risultatu, dbeaver, cum'è una vera applicazione, hè statu scrittu nantu à a piattaforma Eclipse cù u framework OSGi. Per i sviluppatori sperimentati, sta cosa rende cunvene à gestisce e dependenzii, ma per mè era più cum'è magia scura, per quale ùn era chjaramente micca pronta: cum'è solitu, importate e classi chì aghju bisognu da a biblioteca json-simple in l'intestazione di a classa editata, specificate in u pom.xml, dopu à quale u prugettu ricusà categuricamente di assemblà nurmale è crash with errors.

À a fine, aghju sappiutu riparà l'errore di custruzzione: aghju registratu a biblioteca micca in pom.xml, ma in u manifest.mf manifest, cum'è necessariu da OSGI, mentre chì l'specifica cum'è import-package. Ùn hè micca a suluzione più bella, ma funziona. Allora apparsu a prossima sorpresa. Sè vo site in u sviluppu in Intellij Idea, ùn pudete micca solu andà è cumincià à debugging u vostru prughjettu basatu nantu à a piattaforma eclipse: un sviluppatore inespertu ùn deve soffre micca menu di un analista senza cumpleta di a dumanda. I sviluppatori di castori stessi sò ghjunti à a salvezza, indicà in a wiki tutti i balli cù un tamburinu chì deve esse fattu. A cosa più fastidiosa hè chì ancu dopu à tutti questi squats, u prugettu ùn vulia micca esse lanciatu in debug cù a libreria json cunnessa via import-package (malgradu u fattu chì era sempre assemblatu bè in u pruduttu finitu).

À quellu tempu, aghju digià capitu l'inconveniente di utilizà json per u mo compitu - dopu tuttu, i metadati duverebbe esse editatu manualmente, è u furmatu xml hè megliu adattatu per questu. U sicondu argumentu in favore di xml era a prisenza di tutte e classi necessarie in u JDK, chì hà permessu di piantà a lotta cù una biblioteca esterna. Cù assai piacè, aghju trasfirutu tutte e metadata da json à xml è hà cuminciatu à edità a logica autocomplete.

Esempiu di metadata

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

In u risultatu, I hà fattu cambiamenti in e classi SQLUtils è SQLCompletionAnalyzer. L'idea hè questu: se u prugramma ùn hà micca pussutu truvà suggerimenti autocomplete adattati utilizendu a logica di basa, allora verifica a presenza di pussibuli unisce cù un schedariu xml esternu. U schedariu stessu guarda coppie di tavule chì indicanu i campi da quale sti tavulini anu da esse ligati. E restrizioni à e date di validità tecnica di i registri eff_dttm è exp_dttm è a bandiera di eliminazione logica deleted_ind sò stabilite per difettu.

Quandu i cambiamenti sò stati fatti à u codice, a quistione hè stata - quale hà da riempie u schedariu cù metadata? Ci hè parechje entità in u repository, hè caru per registrà tutte e cunnessione stessu. In u risultatu, aghju decisu di assignà stu compitu à i mo cumpagni analisti. Aghju publicatu u schedariu di metadata in svn, da induve un checkout hè fattu à u cartulare locale cù u prugramma. U principiu hè questu: una nova entità hè apparsu in u repository? Un analista inserisce pussibuli unisce in u schedariu, cummette cambiamenti, u restu verificate per sè stessu è gode di l'autocumplementu di travagliu: cumunità, accumulazione di cunniscenze è tuttu ciò. Conduttu un attellu nantu à l'usu di u prugramma per i culleghi, hà scrittu un articulu in Confluence - avà a cumpagnia hà un strumentu più convenientu.

U travagliu nantu à sta funzione m'hà datu a capiscitura chì ùn ci hè bisognu di teme di tinker cù prughjetti open source - in regula, anu una architettura chjara, è ancu a cunniscenza basica di a lingua serà abbastanza per esperimenti. È cun una certa persistenza, puderete ancu sbarazzà di l'operazioni di rutina odiate, risparmiendu u tempu per novi esperimenti.

Source: www.habr.com