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

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

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

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

С първата точка се справих доста бързо — намерих в баг трекера заявка за корекция на автоматичното попълване и в свързаното коммит открих класа 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