Да ли волите да понављате рутинске операције изнова и изнова? Тако да немам. Али сваки пут када сам радио са складиштем Ростелецом-а у СКЛ клијенту, морао сам ручно да региструјем све спојеве између табела. И то упркос чињеници да су се у 90% случајева поља и услови за спајање табела поклапали од упита до упита! Чини се да сваки СКЛ клијент има функције аутоматског довршавања, али за складишта то не функционише увек: они ретко укључују јединствено ограничење и страни кључ како би побољшали перформансе, а без тога програм неће знати како су ентитети повезани са сваким од њих. друго и шта може да учини за вас.
Прошавши кроз порицање, бес, цјенкање, депресију и приближавање прихватању, одлучио сам – зашто не бих покушао сам да имплементирам аутоматско попуњавање Блацкјацк-ом и то на прави начин? Користим дбеавер клијент, написан на Јави, има верзију заједнице отвореног кода. Сазрео је једноставан план:
- Пронађите класе у изворном коду које су одговорне за аутоматско довршавање
- Преусмерите их да раде са спољним метаподацима и одатле извлаче информације о удруживању
- ??
- ПРОФИТ
Прву тачку сам схватио прилично брзо - пронашао сам захтев у алату за праћење грешака да прилагодим аутоматско попуњавање иу повезаном открио класу СКЛЦомплетионАнализер. Погледао сам код и то је оно што ми треба. Остаје само да се препише тако да све функционише. Сачекао сам слободно вече и почео да размишљам о имплементацији. Одлучио сам да напишем правила повезивања табеле (метаподатке) у јсон-у. Нисам имао практичног искуства у раду са овим форматом и тренутни задатак је виђен као прилика да се овај пропуст исправи.
За рад са јсон-ом одлучио сам да користим библиотеку од Гоогле-а. Ту су почела изненађења. Како се испоставило, дбеавер, као права апликација, написан је на платформи Ецлипсе користећи оквир ОСГи. За искусне програмере, ова ствар олакшава управљање зависностима, али за мене је то више личило на мрачну магију, за коју очигледно нисам био спреман: као и обично, увозим класе које су ми потребне из јсон-симпле библиотеке у заглављу уређену класу, наведите је у пом.кмл, након чега пројекат категорички одбија да се нормално саставља и руши са грешкама.
На крају сам успео да исправим грешке у изградњи: регистровао сам библиотеку не у пом.кмл, већ у манифест.мф манифесту, како захтева ОСГИ, док сам је навео као импорт-пацкаге. Није најлепше решење, али функционише. Онда се појавило следеће изненађење. Ако развијате у Интеллиј Идеа-и, не можете само да одете и почнете да отклањате грешке у свом пројекту заснованом на ецлипсе платформи: неискусни програмер би требало да трпи ништа мање од аналитичара без довршавања упита. Сами програмери даброва су прискочили у помоћ, указујући на вики све плесове са тамбуром који треба да се ураде. Најнеугодније је то што ни после свих ових сквотова пројекат није желео да се покрене у дебуг-у са јсон библиотеком повезаном преко импорт-пакета (иако је и даље успешно склопљена у готов производ).
У то време сам већ схватио непријатност коришћења јсон-а за свој задатак - на крају крајева, метаподаци је требало да се уређују ручно, а кмл формат је за то погоднији. Други аргумент у корист кмл-а било је присуство свих потребних класа у ЈДК-у, што је омогућило престанак борбе са спољном библиотеком. Са великим задовољством пренео сам све метаподатке из јсон у кмл и почео да уређујем логику аутокомплета.
Пример метаподатака
<?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>Као резултат тога, И у класе СКЛУтилс и СКЛЦомплетионАнализер. Идеја је следећа: ако програм није могао да пронађе одговарајуће предлоге за аутодовршавање користећи основну логику, онда проверава присуство могућих спајања помоћу екстерне кмл датотеке. Сама датотека чува парове табела које означавају поља помоћу којих ове табеле треба да буду повезане. Ограничења у погледу датума техничке ваљаности записа ефф_дттм и екп_дттм и заставица логичког брисања делетед_инд су подразумевано постављена.
Када су унете измене кода, поставило се питање – ко ће испунити датотеку метаподацима? Постоји много ентитета у спремишту, скупо је да сами региструјете све везе. Као резултат тога, одлучио сам да овај задатак доделим својим колегама аналитичарима. Поставио сам датотеку метаподатака у свн, одакле се врши преузимање у локални директоријум са програмом. Принцип је следећи: да ли се нови ентитет појавио у спремишту? Један аналитичар уноси могућа спајања у фајл, урезује измене, остали се сами проверавају и уживају у радном аутоматском довршавању: заједница, акумулација знања и све то. Одржао радионицу о коришћењу програма за колеге, написао чланак у Цонфлуенце - сада компанија има још један погоднији алат.
Рад на овој особини ми је дао разумевање да нема потребе да се плашим петљања са пројектима отвореног кода - они по правилу имају јасну архитектуру, па ће чак и основно познавање језика бити довољно за експерименте. А уз одређену дозу упорности, чак ћете моћи да се ослободите омражених рутинских операција, штедећи време за нове експерименте.
Извор: ввв.хабр.цом