Обичате ли да повтаряте рутинни операции отново и отново? Така че не го правя. Но всеки път в SQL клиента, когато работех с хранилището на Rostelecom, трябваше да регистрирам всички съединения между таблиците ръчно. И това въпреки факта, че в 90% от случаите полетата и условията за свързване на таблици съвпадаха от заявка до заявка! Изглежда, че всеки SQL клиент има функции за автоматично довършване, но за хранилища това не винаги работи: те рядко включват уникално ограничение и външен ключ, за да подобрят производителността, и без това програмата няма да знае как обектите са свързани с всеки друго и какво може да направи за вас предлага.
След като преминах през отричане, гняв, пазарене, депресия и приближаване на приемането, реших - защо да не опитам сам да внедря автоматично попълване с блекджек и да го направя по правилния начин? Използвам клиента dbeaver, написан на java, има версия на общността с отворен код. Един прост план е узрял:
- Намерете класове в изходния код, които отговарят за автоматичното довършване
- Пренасочете ги да работят с външни метаданни и да изтеглят информация за обединения от там
- ???
- ПЕЧАЛБА
Разбрах първата точка доста бързо - намерих заявка в програмата за проследяване на грешки за коригиране на автоматичното попълване и в свързаните
За да работя с json реших да използвам библиотеката
В крайна сметка успях да поправя грешките при компилирането: регистрирах библиотеката не в 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>
В резултат на това аз
Когато бяха направени промени в кода, възникна въпросът - кой ще попълни файла с метаданни? В хранилището има много обекти, скъпо е да регистрирате сами всички връзки. В резултат на това реших да възложа тази задача на колегите си анализатори. Публикувах файла с метаданни в svn, откъдето се прави проверка в локалната директория с програмата. Принципът е следният: появи ли се нов обект в хранилището? Един анализатор въвежда възможни присъединявания във файла, ангажира промените, останалите проверяват за себе си и се наслаждават на работещото автоматично довършване: общност, натрупване на знания и всичко това. Проведе семинар за използване на програмата за колеги, написа статия в Confluence - сега компанията има още един удобен инструмент.
Работата по тази функция ми даде разбирането, че няма нужда да се страхувате да се занимавате с проекти с отворен код - като правило те имат ясна архитектура и дори основно познаване на езика ще бъде достатъчно за експерименти. И с известна доза постоянство дори ще можете да се отървете от омразните рутинни операции, спестявайки си време за нови експерименти.
Източник: www.habr.com