ProHoster > блог > адміністраванне > Як перастаць рабіць адно і тое ж

Як перастаць рабіць адно і тое ж

Вы кахаеце з разу ў раз паўтараць руцінныя аперацыі? Вось і я не. Але кожны раз у SQL-кліенце пры працы са сховішчам Ростелекома прыходзілася прапісваць усе джойны паміж табліцамі ручкамі. І гэта пры тым, што ў 90% выпадкаў поля і ўмовы злучэння табліц супадалі ад запыту да запыту! Здавалася б, любы SQL-кліент мае функцыі аўтазапаўнення, але для сховішчаў яно не заўсёды працуе: у іх рэдка заводзяцца unique constraint і foreign key у мэтах падвышэння прадукцыйнасці, а без гэтага праграме не пазнаць, як паміж сабой злучаны сутнасці і што яна можа табе прапанаваць.

Як перастаць рабіць адно і тое ж

Прайшоўшы праз адмаўленне, гнеў, гандаль, дэпрэсію і набліжаючыся да прыняцця, я вырашыў - а чаму б самому не паспрабаваць рэалізаваць аўтазапаўненне з блэкджэкам і як належыць? Я карыстаюся кліентам dbeaver, напісаным на java, у яго ёсць кам'юніці версія з адчыненым зыходным кодам. Саспеў няхітры план:

  1. Знайсці ў зыходным кодзе класы, якія адказваюць за аўтазапаўненне
  2. Пераарыентаваць іх на працу з вонкавымі метададзенымі і падцягваць адтуль інфармацыю аб джойнах
  3. ???
  4. ПРЫБЫТАК

З першым пунктам досыць хутка разабраўся - знайшоў у багтрэкеры запыт на карэкціроўку аўтазапаўнення і ў звязаным. каментар выявіў клас SQLCompletionAnalyzer. Паглядзеў код - тое, што трэба. Засталося перапісаць яго так, каб усё працавала. Дачакаўся вольнага вечара і пачаў прадумваць рэалізацыю. Правілы сувязяў табліц (метададзеныя) вырашыў весці ў json. У мяне не было практычнага досведу працы з гэтым фарматам і бягучая задача бачылася магчымасцю гэты недагляд выправіць.

Для працы з json вырашыў выкарыстоўваць бібліятэку json-simple ад гугла. Тут пачаліся сюрпрызы. Як высветлілася, dbeaver, як труъ-дадатак, напісаны на платформе экліпса з выкарыстаннем OSGi-фрэймворка. Для вопытных распрацоўшчыкаў гэтая штука дае зручнасць кіравання залежнасцямі, для мяне ж больш была падобная на цёмную магію, да якой я быў відавочна не гатовы: як звычайна прапісваю імпарт патрэбных мне класаў з бібліятэкі json-simple у шапцы рэдагуемага класа, паказваю яе ў pom. xml, пасля чаго праект катэгарычна адмаўляецца нармальна збірацца і валіцца з памылкамі.

Выправіць памылкі зборкі ў выніку атрымалася: прапісаў бібліятэку не ў pom.xml, а ў маніфесце manifest.mf, як таго патрабуе OSGI, пры гэтым паказаўшы яе як import-package. Не самае прыгожае рашэнне, але затое працуе. Тут з'явілася наступная неспадзеўка. Калі ты вядзеш распрацоўку ў intellij idea, нельга проста так узяць і запусціць дэбаг свайго праекту, заснаванага на платформе eclipse: неспрактыкаваны распрацоўнік павінен пакутаваць не менш, чым аналітык без аўтададатку запытаў. На дапамогу прыйшлі самі распрацоўшчыкі бабра, якія паказалі ў wiki усе танцы з бубнам, якія трэба зрабіць. Самае крыўднае, што нават пасля ўсіх гэтых прысяданняў праект не жадаў запускацца ў дэбазе з падлучанай праз import-package бібліятэкай json (прытым, што ў гатовы прадукт ён па-ранейшаму паспяхова збіраўся).

Да таго моманту я паспеў прачуць нязручнасць выкарыстання json для маёй задачы - усёткі метададзеныя меркавалася рэдагаваць уручную, і для гэтага фармат xml лепш падыходзіць. Другім аргументам у карысць xml была наяўнасць у JDK усіх неабходных класаў, што дало магчымасць спыніць дужанне з вонкавай бібліятэкай. З вялікім задавальненнем перанёс усе метададзеныя з json у xml і прыступіў да праўкаў логікі аўтазапаўнення.

Прыклад метададзеных

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

У выніку я унёс змены у класы SQLUtils і SQLCompletionAnalyzer. Ідэя такая: калі прозе не атрымалася падабраць прыдатныя прапановы аўтазапаўнення па базавай логіцы, то яна правярае наяўнасць магчымых джойнаў па вонкавым файле xml. У самім файле захоўваюцца пары табліц з указаннем палёў, па якіх гэтыя табліцы трэба злучаць. Абмежаванні на тэхнічныя даты дзеяння запісаў eff_dttm і exp_dttm і сцяг лагічнага выдалення deleted_ind пры гэтым прастаўляюцца па змаўчанні.

Калі змяненні ў код былі ўнесены, паўстала пытанне - хто будзе напаўняць файл з метададзенымі? Сутнасцяў у сховішчы шмат, самому ўсе сувязі прапісваць накладна. У выніку вырашыў павесіць гэтую задачу на сваіх калег-аналітыкаў. Файл метададзеных выклаў у svn, адкуль робіцца чакаюць у лакальную дырэкторыю з праграмай. Прынцып такі: у сховішчы з'явілася новая сутнасць? Адзін аналітык уносіць магчымыя джойны ў файл, камітіт змены, астатнія робяць чакаюць да сябе і атрымліваюць асалоду ад працуючым аўтазапаўненнем: кам'юніці, назапашванне ведаў і ўсё такое. Правёў для калегаў воркшоп па выкарыстанні прогі, напісаў артыкул у канфлюенс — зараз у кампаніі адной зручнай прыладай больш.

Праца над гэтай фічай дала мне разуменне, што не варта баяцца калупаць апенсорсныя праекты — як правіла, у іх зразумелая архітэктура, і нават базавых ведаў мовы будзе дастаткова для эксперыментаў. А пры вызначанай дзелі зацятасці нават атрымаецца пазбавіцца ад ненавісных руцінных аперацый, зэканоміўшы сабе час на новыя эксперыменты.

Крыніца: habr.com

Дадаць каментар