Дали сакате да повторувате рутински операции одново и одново? Па јас не. Но, секој пат кога во клиентот SQL кога работев со складиштето на Ростелеком, морав рачно да ги регистрирам сите спојувања помеѓу табелите. И ова и покрај фактот што во 90% од случаите полињата и условите за приклучување на табелите се совпаѓаа од барање до барање! Се чини дека секој клиент на SQL има функции за автоматско завршување, но за складиштата тоа не секогаш функционира: тие ретко вклучуваат уникатно ограничување и странски клуч со цел да се подобрат перформансите, а без ова програмата нема да знае како ентитетите се поврзани со секој друго и што може да направи за вас.
Поминувајќи низ негирање, лутина, пазарење, депресија и приближување кон прифаќање, решив - зошто да не се обидам сам да го имплементирам автоматското полнење со блек џек и да го направам тоа на вистински начин? Го користам клиентот dbeaver, напишан во java, има верзија на заедницата со отворен код. Едноставен план е созреан:
- Најдете класи во изворниот код кои се одговорни за автоматско пополнување
- Пренасочете ги да работат со надворешни метаподатоци и извлечете ги информациите за приклучоците од таму
- ???
- ДОБИВКА
Првата точка ја сфатив доста брзо - најдов барање во тракерот за грешки за прилагодување на автоматското пополнување и во поврзаните
За да работам со json, решив да ја користам библиотеката
На крајот, успеав да ги поправам грешките во изградбата: ја регистрирав библиотеката не во pom.xml, туку во манифестот manifest.mf, како што бара OSGI, додека ја наведов како увоз-пакет. Не е најубавото решение, но функционира. Тогаш се појави следното изненадување. Ако се развивате во Intellij Idea, не можете само да одите и да започнете со дебагирање на вашиот проект врз основа на платформата за затемнување: неискусен развивач треба да страда не помалку од аналитичар без завршување на барањето. Самите развивачи на дабар дојдоа на помош, укажувајќи на викито сите танци со тамбура што треба да се направат. Најдосадно е што и после сите овие сквотови, проектот не сакаше да биде лансиран во дебагирање со библиотеката json поврзана преку увоз-пакет (и покрај фактот што сè уште беше успешно склопен во готовиот производ).
До тоа време, веќе ја сфатив непријатноста од користењето 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