Kiel ĉesi fari la samon

Ĉu vi ŝatas ripeti rutinajn operaciojn denove kaj denove? Do mi ne faras. Sed ĉiufoje en la SQL-kliento laborante kun la stokado Rostelecom, mi devis registri ĉiujn kuniĝojn inter la tabeloj permane. Kaj ĉi tio malgraŭ tio, ke en 90% de kazoj la kampoj kaj kondiĉoj por kunigi tabelojn koincidis de peto al peto! Ŝajnus, ke iu ajn SQL-kliento havas aŭtomatajn kompletigajn funkciojn, sed por stokado ĝi ne ĉiam funkcias: ili malofte inkluzivas unikan limigon kaj fremdan ŝlosilon por plibonigi rendimenton, kaj sen tio la programo ne scios kiel entoj rilatas al ĉiu. alia kaj kion ĝi povas fari por vi proponas.

Travivinte neon, koleron, marĉandon, deprimon kaj alproksimiĝante al akcepto, mi decidis - kial ne provi mem efektivigi aŭtomatan plenigon per blackjack kaj fari ĝin ĝuste? Mi uzas la dbeaver-klienton, skribitan en java, ĝi havas liberkodan komunuman version. Simpla plano maturiĝis:

1. Trovu klasojn en la fontkodo, kiuj respondecas pri aŭtomata kompletigo
2. Redirektu ilin por labori kun eksteraj metadatenoj kaj tiri informojn pri kuniĝoj de tie
3. ??????
4. PROFITO

Mi eltrovis la unuan punkton sufiĉe rapide - mi trovis peton en la cimspurilo por ĝustigi la aŭtomatan plenigon kaj en la rilata kompromiti malkovris la klason SQLCompletionAnalyzer. Mi rigardis la kodon kaj ĝi estas tio, kion mi bezonas. Restas nur reverki ĝin, por ke ĉio funkciu. Mi atendis liberan vesperon kaj komencis pripensi la efektivigon. Mi decidis skribi tabelajn ligajn regulojn (metadatenojn) en json. Mi havis neniun praktikan sperton laborante kun ĉi tiu formato kaj la nuna tasko estis vidita kiel ŝanco korekti ĉi tiun preterlason.

Por labori kun json mi decidis uzi la bibliotekon json-simple de Guglo. Ĉi tie komenciĝis la surprizoj. Kiel rezultis, dbeaver, kiel vera aplikaĵo, estis skribita sur la Eclipse-platformo uzante la kadron OSGi. Por spertaj programistoj, ĉi tiu afero konvenas administri dependecojn, sed por mi ĝi estis pli kiel malhela magio, por kiu mi klare ne estis preta: kiel kutime, mi importas la klasojn kiujn mi bezonas el la json-simple biblioteko en la kaplinio de la redaktita klaso, specifu ĝin en la pom.xml, post kio la projekto kategorie rifuzas kunveni normale kaj kraŝas pro eraroj.

Finfine, mi sukcesis ripari la konstru-erarojn: mi registris la bibliotekon ne en pom.xml, sed en la manifest.mf manifesto, kiel postulite de OSGI, dum specifis ĝin kiel import-pakaĵo. Ne la plej bela solvo, sed ĝi funkcias. Tiam aperis la sekva surprizo. Se vi disvolvas en Intellij Idea, vi ne povas simple iri kaj komenci sencimigi vian projekton surbaze de la eklipso-platformo: nesperta programisto devus suferi ne malpli ol analizisto sen konsultkompletigo. La kastoraj programistoj mem venis al la savo, indikante en la vikio ĉiujn dancojn kun tamburino, kiujn oni devas fari. La plej ĝena afero estas, ke eĉ post ĉiuj ĉi kaŭzoj, la projekto ne volis esti lanĉita en sencimigo kun la json-biblioteko konektita per import-pakaĵo (malgraŭ la fakto, ke ĝi estis ankoraŭ sukcese kunmetita en la pretan produkton).

Tiam mi jam rimarkis la malkomforton uzi json por mia tasko - ja la metadatumoj devis esti redaktitaj permane, kaj la xml-formato pli taŭgas por tio. La dua argumento favore al xml estis la ĉeesto de ĉiuj necesaj klasoj en la JDK, kio ebligis ĉesi batali kun ekstera biblioteko. Kun granda plezuro, mi transdonis ĉiujn metadatumojn de json al xml kaj komencis redakti la aŭtokompletan logikon.

Ekzemplo de metadatumoj

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

Rezulte mi faris ŝanĝojn en la klasojn SQLUtils kaj SQLCompletionAnalyzer. La ideo estas jena: se la programo ne povis trovi taŭgajn aŭtokompletajn sugestojn uzante la bazan logikon, tiam ĝi kontrolas la ĉeeston de eblaj kuniĝoj per ekstera xml-dosiero. La dosiero mem konservas parojn da tabeloj indikante la kampojn per kiuj tiuj tabeloj devas esti ligitaj. Limigoj pri la teknikaj validecaj datoj de registroj eff_dttm kaj exp_dttm kaj la logika foriga flago deleted_ind estas agordita defaŭlte.

Kiam oni faris ŝanĝojn al la kodo, aperis la demando - kiu plenigos la dosieron per metadatumoj? Estas multaj estaĵoj en la deponejo, estas multekoste registri ĉiujn ligojn mem. Rezulte, mi decidis atribui ĉi tiun taskon al miaj kolegaj analizistoj. Mi afiŝis la metadatuman dosieron en svn, de kie oni kontrolas al la loka dosierujo kun la programo. La principo estas jena: ĉu nova ento aperis en la deponejo? Unu analizisto enmetas eblajn kuniĝojn en la dosieron, faras ŝanĝojn, la ceteraj kontrolas al si mem kaj ĝuas la funkcian aŭtomatan kompletigon: komunumo, amasiĝo de scio kaj ĉio tio. Faris laborrenkontiĝon pri uzado de la programo por kolegoj, verkis artikolon en Confluence - nun la firmao havas unu pli oportunan ilon.

Labori pri ĉi tiu funkcio donis al mi la komprenon, ke ne necesas timi tuŝi malfermfontajn projektojn - kiel regulo ili havas klaran arkitekturon, kaj eĉ baza scio de la lingvo sufiĉos por eksperimentoj. Kaj kun certa kvanto da persisto, vi eĉ povos forigi malamatajn rutinajn operaciojn, ŝparante al vi tempon por novaj eksperimentoj.

fonto: www.habr.com