Вы кахаеце з разу ў раз паўтараць руцінныя аперацыі? Вось і я не. Але кожны раз у SQL-кліенце пры працы са сховішчам Ростелекома прыходзілася прапісваць усе джойны паміж табліцамі ручкамі. І гэта пры тым, што ў 90% выпадкаў поля і ўмовы злучэння табліц супадалі ад запыту да запыту! Здавалася б, любы SQL-кліент мае функцыі аўтазапаўнення, але для сховішчаў яно не заўсёды працуе: у іх рэдка заводзяцца unique constraint і foreign key у мэтах падвышэння прадукцыйнасці, а без гэтага праграме не пазнаць, як паміж сабой злучаны сутнасці і што яна можа табе прапанаваць.
Прайшоўшы праз адмаўленне, гнеў, гандаль, дэпрэсію і набліжаючыся да прыняцця, я вырашыў - а чаму б самому не паспрабаваць рэалізаваць аўтазапаўненне з блэкджэкам і як належыць? Я карыстаюся кліентам dbeaver, напісаным на java, у яго ёсць кам'юніці версія з адчыненым зыходным кодам. Саспеў няхітры план:
- Знайсці ў зыходным кодзе класы, якія адказваюць за аўтазапаўненне
- Пераарыентаваць іх на працу з вонкавымі метададзенымі і падцягваць адтуль інфармацыю аб джойнах
- ???
- ПРЫБЫТАК
З першым пунктам досыць хутка разабраўся - знайшоў у багтрэкеры запыт на карэкціроўку аўтазапаўнення і ў звязаным.
Для працы з json вырашыў выкарыстоўваць бібліятэку
Выправіць памылкі зборкі ў выніку атрымалася: прапісаў бібліятэку не ў 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>
У выніку я
Калі змяненні ў код былі ўнесены, паўстала пытанне - хто будзе напаўняць файл з метададзенымі? Сутнасцяў у сховішчы шмат, самому ўсе сувязі прапісваць накладна. У выніку вырашыў павесіць гэтую задачу на сваіх калег-аналітыкаў. Файл метададзеных выклаў у svn, адкуль робіцца чакаюць у лакальную дырэкторыю з праграмай. Прынцып такі: у сховішчы з'явілася новая сутнасць? Адзін аналітык уносіць магчымыя джойны ў файл, камітіт змены, астатнія робяць чакаюць да сябе і атрымліваюць асалоду ад працуючым аўтазапаўненнем: кам'юніці, назапашванне ведаў і ўсё такое. Правёў для калегаў воркшоп па выкарыстанні прогі, напісаў артыкул у канфлюенс — зараз у кампаніі адной зручнай прыладай больш.
Праца над гэтай фічай дала мне разуменне, што не варта баяцца калупаць апенсорсныя праекты — як правіла, у іх зразумелая архітэктура, і нават базавых ведаў мовы будзе дастаткова для эксперыментаў. А пры вызначанай дзелі зацятасці нават атрымаецца пазбавіцца ад ненавісных руцінных аперацый, зэканоміўшы сабе час на новыя эксперыменты.
Крыніца: habr.com