🥇Hvernig á að hætta að gera það sama

Finnst þér gaman að endurtaka venjulegar aðgerðir aftur og aftur? Svo ég geri það ekki. En í hvert skipti sem ég var í SQL biðlaranum þegar ég var að vinna með Rostelecom geymslunni þurfti ég að skrá allar samskeytin á milli borðanna handvirkt. Og þetta þrátt fyrir að í 90% tilvika hafi reitirnir og skilyrðin til að sameina töflur fallið saman frá fyrirspurn til fyrirspurnar! Það virðist sem allir SQL biðlarar hafi sjálfvirka útfyllingaraðgerðir, en fyrir geymslur virkar það ekki alltaf: þeir innihalda sjaldan einstaka þvingun og erlendan lykil til að bæta afköst, og án þess mun forritið ekki vita hvernig einingar tengjast hverjum og einum. annað og hvað það getur gert fyrir þig að bjóða.

Eftir að hafa gengið í gegnum afneitun, reiði, samningaviðræður, þunglyndi og nálgast viðurkenningu ákvað ég - hvers vegna ekki að reyna að innleiða sjálfvirka útfyllingu með blackjack sjálfur og gera það á réttan hátt? Ég nota dbeaver biðlarann, skrifaðan í java, hann er með opinn uppspretta samfélagsútgáfu. Einföld áætlun hefur þroskast:

Finndu flokka í frumkóðanum sem bera ábyrgð á sjálfvirkri útfyllingu
Beindu þeim til að vinna með ytri lýsigögn og draga upplýsingar um tengingar þaðan
???
Hagnaður

Ég fattaði fyrsta atriðið nokkuð fljótt - ég fann beiðni í villurekki um að stilla sjálfvirka útfyllingu og í tengdum skuldbinda sig uppgötvaði SQLCompletionAnalyzer flokkinn. Ég skoðaði kóðann og hann er það sem ég þarf. Það eina sem er eftir er að endurskrifa það þannig að allt virki. Ég beið eftir lausu kvöldi og fór að hugsa um útfærsluna. Ég ákvað að skrifa töflutenglareglur (lýsigögn) í json. Ég hafði enga hagnýta reynslu af því að vinna með þetta snið og var litið á núverandi verkefni sem tækifæri til að leiðrétta þessa aðgerðaleysi.

Til að vinna með json ákvað ég að nota bókasafnið json-einfalt frá Google. Þetta er þar sem óvæntingar hófust. Eins og það kom í ljós, var dbeaver, sem sannkallað forrit, skrifað á Eclipse pallinum með því að nota OSGi ramma. Fyrir reynda forritara gerir þetta það þægilegt að stjórna ósjálfstæði, en fyrir mig var það meira eins og myrkur galdur, sem ég var greinilega ekki tilbúinn fyrir: eins og venjulega flyt ég inn flokkana sem ég þarf frá json-simple bókasafninu í hausnum á breytta bekknum, tilgreindu hann í pom.xml, eftir það neitar verkefnið afdráttarlaust að setja saman venjulega og hrynur með villum.

Á endanum tókst mér að laga byggingarvillurnar: Ég skráði bókasafnið ekki í pom.xml, heldur í manifest.mf upplýsingaskránni, eins og OSGI krefst, en tilgreindi það sem innflutningspakka. Ekki fallegasta lausnin en hún virkar. Svo kom næsta óvart. Ef þú ert að þróa í Intellij Idea geturðu ekki bara farið og byrjað að kemba verkefnið þitt á grundvelli Eclipse vettvangsins: óreyndur verktaki ætti að þjást ekki minna en sérfræðingur án þess að ljúka fyrirspurn. Bónaframleiðendurnir komu sjálfir til bjargar og tilgreindu á wiki alla dansana með tambúrínu sem þarf að gera. Það sem er mest pirrandi er að jafnvel eftir allar þessar hnébeygjur, vildi verkefnið ekki koma af stað í villuleit með json bókasafninu tengt í gegnum innflutningspakka (þrátt fyrir þá staðreynd að það væri enn vel sett saman í fullunna vöru).

Á þeim tíma var ég búinn að átta mig á óþægindum þess að nota json fyrir verkefnið mitt - þegar allt kemur til alls átti að breyta lýsigögnunum handvirkt og xml sniðið hentar betur fyrir þetta. Önnur rökin fyrir xml voru tilvist allra nauðsynlegra flokka í JDK, sem gerði það mögulegt að hætta að berjast við utanaðkomandi bókasafn. Með mikilli ánægju flutti ég öll lýsigögn frá json yfir í xml og byrjaði að breyta sjálfvirkri útfyllingu rökfræði.

Dæmi um lýsigögn

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

Þar af leiðandi ég gert breytingar í SQLUtils og SQLCompletionAnalyzer flokkana. Hugmyndin er þessi: ef forritið gat ekki fundið viðeigandi uppástungur um sjálfvirka útfyllingu með því að nota grunnrógíkina, þá athugar það hvort mögulegar tengingar séu til staðar með því að nota utanaðkomandi xml skrá. Skráin sjálf geymir pör af töflum sem gefa til kynna reiti sem þessar töflur þurfa að vera tengdar við. Takmarkanir á tæknilegum gildisdögum færslur eff_dttm og exp_dttm og rökrétt eyðingarfáni deleted_ind eru sjálfgefið stilltar.

Þegar breytingar voru gerðar á kóðanum vaknaði spurningin - hver mun fylla skrána af lýsigögnum? Það eru fullt af aðilum í geymslunni, það er dýrt að skrá allar tengingar sjálfur. Þar af leiðandi ákvað ég að fela þessum sérfræðingum mínum þetta verkefni. Ég setti lýsigagnaskrána inn í svn, þaðan sem farið er yfir í staðbundna möppuna með forritinu. Meginreglan er þessi: hefur ný eining birst í geymslunni? Einn sérfræðingur færir mögulega tengingu inn í skrána, framkvæmir breytingar, hinir skoða sjálfir og njóta sjálfvirkrar útfyllingar: samfélag, þekkingarsöfnun og allt það. Hélt vinnustofu um notkun forritsins fyrir samstarfsmenn, skrifaði grein í Confluence - nú hefur fyrirtækið enn eitt þægilegt tól.

Vinna við þennan eiginleika gaf mér þann skilning að það er engin þörf á að vera hræddur við að fikta við opinn hugbúnað - að jafnaði hafa þau skýran arkitektúr og jafnvel grunnþekking á tungumálinu mun duga fyrir tilraunir. Og með ákveðinni þrautseigju muntu jafnvel geta losað þig við hataðar venjubundnar aðgerðir, sem sparar þér tíma fyrir nýjar tilraunir.

Heimild: www.habr.com

Hvernig á að hætta að gera það sama

Bæta við athugasemd Hætta við svar