Hoe om op te hou om dieselfde ding te doen

Hou jy daarvan om roetine-operasies oor en oor te herhaal? So ek doen nie. Maar elke keer in die SQL-kliënt toe ek met die Rostelecom-berging gewerk het, moes ek al die verbindings tussen die tabelle met die hand registreer. En dit ten spyte van die feit dat in 90% van die gevalle die velde en voorwaardes vir die koppeling van tabelle van navraag tot navraag saamgeval het! Dit wil voorkom asof enige SQL-kliënt outo-voltooiingsfunksies het, maar vir bergings werk dit nie altyd nie: hulle sluit selde unieke beperking en vreemde sleutel in om werkverrigting te verbeter, en daarsonder sal die program nie weet hoe entiteite met elkeen verband hou nie. ander en wat dit vir jou kan doen.

Nadat ek deur ontkenning, woede, bedinging, depressie en naderende aanvaarding gegaan het, het ek besluit - hoekom nie self probeer om outovul met blackjack te implementeer en dit op die regte manier te doen nie? Ek gebruik die dbeaver-kliënt, geskryf in java, dit het 'n oopbron-gemeenskapsweergawe. 'n Eenvoudige plan het volwasse geword:

1. Vind klasse in die bronkode wat verantwoordelik is vir outovoltooiing
2. Herlei hulle om met eksterne metadata te werk en trek inligting oor aansluitings van daar af
3. ??
4. WINS

Ek het die eerste punt redelik vinnig uitgepluis - ek het 'n versoek in die foutspoorder gevind om die outovul aan te pas en in die verwante pleeg het die SQLCompletionAnalyzer-klas ontdek. Ek het na die kode gekyk en dit is wat ek nodig het. Al wat oorbly is om dit oor te skryf sodat alles werk. Ek het vir 'n vrye aand gewag en die implementering begin deurdink. Ek het besluit om tabelskakelreëls (metadata) in json te skryf. Ek het geen praktiese ondervinding gehad om met hierdie formaat te werk nie en die huidige taak is gesien as 'n geleentheid om hierdie weglating reg te stel.

Om met json te werk, het ek besluit om die biblioteek te gebruik json-eenvoudig van Google. Dit is waar die verrassings begin het. Soos dit geblyk het, is dbeaver, as 'n ware toepassing, op die Eclipse-platform geskryf met behulp van die OSGi-raamwerk. Vir ervare ontwikkelaars maak hierdie ding dit gerieflik om afhanklikhede te bestuur, maar vir my was dit meer soos donker magie, waarvoor ek duidelik nie gereed was nie: soos gewoonlik voer ek die klasse in wat ek nodig het uit die json-simple biblioteek in die kop van die geredigeerde klas, spesifiseer dit in die pom.xml, waarna die projek kategories weier om normaal te monteer en met foute ineenstort.

Op die ou end het ek daarin geslaag om die boufoute reg te stel: ek het die biblioteek nie in pom.xml geregistreer nie, maar in die manifest.mf-manifes, soos vereis deur OSGI, terwyl ek dit as invoerpakket gespesifiseer het. Nie die mooiste oplossing nie, maar dit werk. Toe verskyn die volgende verrassing. As jy in Intellij Idea ontwikkel, kan jy nie net begin om jou projek te ontfout op grond van die eclipse-platform nie: 'n onervare ontwikkelaar behoort nie minder as 'n ontleder te ly sonder om navraag te voltooi nie. Die beverontwikkelaars het self tot die redding gekom en in die wiki al die danse met 'n tamboeryn aangedui wat gedoen moet word. Die mees irriterende ding is dat die projek, selfs na al hierdie hurk, nie in ontfouting geloods wou word met die json-biblioteek wat via invoerpakket gekoppel is nie (ten spyte daarvan dat dit steeds suksesvol in die voltooide produk saamgestel is).

Teen daardie tyd het ek reeds die ongerief besef om json vir my taak te gebruik - die metadata was immers veronderstel om handmatig geredigeer te word, en die xml-formaat is beter geskik hiervoor. Die tweede argument ten gunste van xml was die teenwoordigheid van al die nodige klasse in die JDK, wat dit moontlik gemaak het om op te hou baklei met 'n eksterne biblioteek. Met groot plesier het ek al die metadata van json na xml oorgedra en die outovoltooi-logika begin redigeer.

Metadata voorbeeld

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

As gevolg hiervan het ek veranderinge aangebring het in die SQLUtils- en SQLCompletionAnalyzer-klasse. Die idee is dit: as die program nie geskikte outovoltooivoorstelle kon vind deur die basiese logika te gebruik nie, dan kyk dit vir die teenwoordigheid van moontlike aansluitings met behulp van 'n eksterne xml-lêer. Die lêer self stoor pare tabelle wat die velde aandui waarmee hierdie tabelle gekoppel moet word. Beperkings op die tegniese geldigheidsdatums van rekords eff_dttm en exp_dttm en die logiese skrapvlag deleted_ind word by verstek gestel.

Toe veranderinge aan die kode aangebring is, het die vraag ontstaan ​​- wie sal die lêer met metadata vul? Daar is baie entiteite in die bewaarplek, dit is duur om al die verbindings self te registreer. Gevolglik het ek besluit om hierdie taak aan my mede-ontleders op te dra. Ek het die metadata-lêer in svn geplaas, vanwaar 'n betaalpunt gemaak word na die plaaslike gids met die program. Die beginsel is dit: het 'n nuwe entiteit in die bewaarplek verskyn? Een ontleder voer moontlike aansluitings in die lêer in, pleeg veranderinge, die res kyk na hulself en geniet die werkende outo-voltooiing: gemeenskap, opbou van kennis en al die dinge. Het 'n werkswinkel oor die gebruik van die program vir kollegas gehou, 'n artikel in Confluence geskryf - nou het die maatskappy nog 'n gerieflike hulpmiddel.

Deur aan hierdie kenmerk te werk, het my die begrip gegee dat dit nie nodig is om bang te wees om met oopbronprojekte te peuter nie - in die reël het hulle 'n duidelike argitektuur, en selfs basiese kennis van die taal sal genoeg wees vir eksperimente. En met 'n sekere mate van volharding, sal jy selfs in staat wees om ontslae te raak van gehate roetine-operasies, wat jouself tyd spaar vir nuwe eksperimente.

Bron: will.com