🥇Како да престанете да го правите истото

Дали сакате да повторувате рутински операции одново и одново? Па јас не. Но, секој пат кога во клиентот SQL кога работев со складиштето на Ростелеком, морав рачно да ги регистрирам сите спојувања помеѓу табелите. И ова и покрај фактот што во 90% од случаите полињата и условите за приклучување на табелите се совпаѓаа од барање до барање! Се чини дека секој клиент на SQL има функции за автоматско завршување, но за складиштата тоа не секогаш функционира: тие ретко вклучуваат уникатно ограничување и странски клуч со цел да се подобрат перформансите, а без ова програмата нема да знае како ентитетите се поврзани со секој друго и што може да направи за вас.

Поминувајќи низ негирање, лутина, пазарење, депресија и приближување кон прифаќање, решив - зошто да не се обидам сам да го имплементирам автоматското полнење со блек џек и да го направам тоа на вистински начин? Го користам клиентот dbeaver, напишан во java, има верзија на заедницата со отворен код. Едноставен план е созреан:

Најдете класи во изворниот код кои се одговорни за автоматско пополнување
Пренасочете ги да работат со надворешни метаподатоци и извлечете ги информациите за приклучоците од таму
???
ДОБИВКА

Првата точка ја сфатив доста брзо - најдов барање во тракерот за грешки за прилагодување на автоматското пополнување и во поврзаните посветат ја откри класата SQLCompletionAnalyzer. Го погледнав кодот и ми треба. Останува само да се преработи за се да функционира. Чекав бесплатна вечер и почнав да размислувам за спроведувањето. Решив да напишам правила за врски на табелата (метаподатоци) во json. Немав практично искуство со работа со овој формат и сегашната задача се гледаше како можност да се поправи овој пропуст.

За да работам со json, решив да ја користам библиотеката json-едноставно од Google. Тука започнаа изненадувањата. Како што се испостави, dbeaver, како вистинска апликација, беше напишана на платформата Eclipse користејќи ја рамката OSGi. За искусни програмери, оваа работа го прави погодно управувањето со зависностите, но за мене тоа беше повеќе како темна магија, за која очигледно не бев подготвен: како и обично, ги увезувам класите што ми се потребни од библиотеката json-simple во заглавието на уредуваната класа, наведете ја во пом.xml, по што проектот категорично одбива да се состави нормално и паѓа со грешки.

На крајот, успеав да ги поправам грешките во изградбата: ја регистрирав библиотеката не во 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>

Како резултат на тоа јас направи промени во класите SQLUtils и SQLCompletionAnalyzer. Идејата е следна: ако програмата не можеше да најде соодветни предлози за автоматско комплетирање користејќи ја основната логика, тогаш проверува присуство на можни спојувања користејќи надворешна xml-датотека. Самата датотека складира парови табели кои ги означуваат полињата со кои треба да се поврзат овие табели. Ограничувањата на датумите на техничка важност на записите eff_dttm и exp_dttm и знамето за логично бришење deleted_ind се поставени стандардно.

Кога беа направени промени во кодот, се појави прашањето - кој ќе ја пополни датотеката со метаподатоци? Има многу ентитети во складиштето, скапо е сами да ги регистрирате сите врски. Како резултат на тоа, решив да им ја доделам оваа задача на моите колеги аналитичари. Фајлот со метаподатоци го поставив во svn, од каде што се врши наплата во локалниот директориум со програмата. Принципот е овој: дали се појави нов ентитет во складиштето? Еден аналитичар внесува можни приклучувања во датотеката, врши промени, останатите проверуваат сами и уживаат во работното автоматско завршување: заедница, акумулација на знаење и сето тоа. Спроведе работилница за користење на програмата за колеги, напиша статија во Confluence - сега компанијата има уште една поудобна алатка.

Работењето на оваа функција ми даде разбирање дека нема потреба да се плашам да се мешам со проекти со отворен код - по правило, тие имаат јасна архитектура, па дури и основното познавање на јазикот ќе биде доволно за експерименти. И со одредена количина на упорност, ќе можете дури и да се ослободите од омразените рутински операции, заштедувајќи си време за нови експерименти.

Извор: www.habr.com

Како да престанете да го правите истото

Додадете коментар Откажи одговор