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

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

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

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

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

За да работя с json реших да използвам библиотеката json-прост от Google. Тук започнаха изненадите. Както се оказа, dbeaver, като истинско приложение, е написано на платформата Eclipse, използвайки рамката OSGi. За опитни разработчици това нещо прави удобно управлението на зависимости, но за мен беше по-скоро като тъмна магия, за която явно не бях готов: както обикновено, импортирам класовете, от които се нуждая, от json-простата библиотека в заглавката на редактирания клас и го посочва в pom.xml, след което проекта категорично отказва да се сглоби нормално и забива с грешки.

В крайна сметка успях да поправя грешките при компилирането: регистрирах библиотеката не в pom.xml, а в манифеста manifest.mf, както се изисква от OSGI, като същевременно я посочих като import-package. Не е най-красивото решение, но работи. Тогава се появи следващата изненада. Ако разработвате в Intellij Idea, не можете просто да отидете и да започнете да отстранявате грешки в проекта си въз основа на платформата eclipse: неопитен разработчик трябва да страда не по-малко от анализатор без завършване на заявка. Самите разработчици на бобър се притекоха на помощ, като посочиха в wiki всички танци с тамбурина, които трябва да се направят. Най-дразнещото е, че дори след всички тези клякания, проектът не искаше да бъде стартиран в debug с json библиотеката, свързана чрез import-package (въпреки факта, че все още беше успешно сглобен в крайния продукт).

По това време вече бях осъзнал неудобството да използвам 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, откъдето се прави проверка в локалната директория с програмата. Принципът е следният: появи ли се нов обект в хранилището? Един анализатор въвежда възможни присъединявания във файла, ангажира промените, останалите проверяват за себе си и се наслаждават на работещото автоматично довършване: общност, натрупване на знания и всичко това. Проведе семинар за използване на програмата за колеги, написа статия в Confluence - сега компанията има още един удобен инструмент.

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

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