🥇Как да спрем да правим едно и също

Обичате ли да повтаряте рутинни операции отново и отново? Аз не. Но всеки път, когато работех с хранилището на Ростелеком в SQL клиента, трябваше ръчно да записвам всички връзки между таблиците. И то, удивително, в 90% от случаите полетата и условията за свързване на таблиците съвпадаха от запитване до запитване! Беше логично, че всеки SQL клиент има функции за автоматично попълване, но за хранилищата това не винаги работи: те рядко имат уникални ограничения и външни ключове с цел повишаване на производителността, а без тях програмата не може да узнае как са свързани сущностите и какво може да ти предложи.

След като преминах през отрицание, гняв, търговия, депресия и се приближавах към приемането, реших — а защо да не опитам сам да реализирам автоматичното попълване с малко късмет и както трябва? Ползвам клиента dbeaver, написан на java, и имам версия с отворен код. Измислих прост план:

Да намеря в изходния код класовете, отговорни за автоматичното попълване
Да ги пренасоча да работят с външни метаданни и да извлекат информация за връзките
??????
ПЕЧАЛБА

С първата точка бързо се справих — намерих в багтракера заявка за корекция на автоматичното попълване и в свързания комит открих класа SQLCompletionAnalyzer. Разгледах кода — точно каквото трябва. Оставаше само да го пренапиша, за да работи. Изчаках свободен следобед и започнах да обмислям реализацията. Правилата за връзки между таблиците (метаданни) реших да запиша в json. Нямах практически опит с този формат и текущата задача ми се стори възможност да поправя това упущение.

За работа с json реших да използвам библиотеката json-simple от google. Тук започнаха изненадите. Както се оказа, dbeaver, като истинско приложение, е написан на платформата eclipse с използване на 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 и започнах да коригирам логиката на автодовършването.

Пример на метаданните

dim_account
        dim_partner
        
        
    
    
        dim_account
        dim_branch

В резултат на това аз внесох изменения в класовете SQLUtils и SQLCompletionAnalyzer. Идеята е следната: ако програмата не успее да намери подходящи предложения за автодовършване по основната логика, тя проверява наличието на възможни джойнове по външния xml файл. В самия файл са записани двойки таблици с указание за полетата, по които тези таблици трябва да се свързват. Ограниченията на техническите дати на действие на записите eff_dttm и exp_dttm, както и флагът за логическо изтриване deleted_ind, се задават по подразбиране.

Когато бяха направени промените в кода, възникна въпросът — кой ще запълва файла с метаданни? В хранилището има много сущности, трудно е сам да опишеш всички връзки. В крайна сметка реших да възложа тази задача на колегите си-аналитици. Файлът с метаданни беше качен в svn, от където се прави чекаут в локалната директория с програмата. Принципът е следният: появи се нова сущност в хранилището? Един аналитик внася възможните джойнове в файла, комитва промените, останалите правят чекаут за себе си и се радват на работещото автоматично попълване: комюнити, натрупване на знания и всичко такова. Проведох за колегите работилница за използването на програмата, написах статия в конфлюенс — сега в компанията има още един удобен инструмент.

Работата по тази функция ми даде разбирането, че не трябва да се страхуваме да ровим в опенсорсни проекти — обикновено те имат ясна архитектура и дори основни познания по езика са достатъчни за експерименти. А с определена доза упорство може да успееш да се освободиш от ненавистните рутинни операции, спестявайки време за нови експерименти.

Източник: habr.com