Hur man slutar göra samma sak

Gillar du att upprepa rutinoperationer om och om igen? Så det gör jag inte. Men varje gång i SQL-klienten när jag arbetade med Rostelecom-lagringen var jag tvungen att registrera alla kopplingar mellan tabellerna manuellt. Och detta trots att fälten och villkoren för att sammanfoga tabeller i 90 % av fallen sammanföll från fråga till fråga! Det verkar som om vilken SQL-klient som helst har funktioner för automatisk komplettering, men för lagringar fungerar det inte alltid: de inkluderar sällan unika begränsningar och främmande nyckel för att förbättra prestanda, och utan detta kommer programmet inte att veta hur entiteter är relaterade till varje annat och vad det kan göra för dig.

Efter att ha gått igenom förnekelse, ilska, förhandlingar, depression och närmade mig acceptans bestämde jag mig - varför inte försöka implementera autofill med blackjack själv och göra det på rätt sätt? Jag använder dbeaver-klienten, skriven i java, den har en communityversion med öppen källkod. En enkel plan har mognat:

1. Hitta klasser i källkoden som är ansvariga för autokomplettering
2. Omdirigera dem till att arbeta med extern metadata och hämta information om anslutningar därifrån
3. ???
4. VINST

Jag kom på den första punkten ganska snabbt - jag hittade en begäran i buggspåraren om att justera autofyllningen och i den relaterade begå upptäckte klassen SQLCompletionAnalyzer. Jag tittade på koden och det är vad jag behöver. Det återstår bara att skriva om det så att allt fungerar. Jag väntade på en ledig kväll och började tänka igenom genomförandet. Jag bestämde mig för att skriva tabelllänksregler (metadata) i json. Jag hade ingen praktisk erfarenhet av att arbeta med detta format och den aktuella uppgiften sågs som en möjlighet att rätta till denna utelämnande.

För att arbeta med json bestämde jag mig för att använda biblioteket json-enkel från Google. Det var här överraskningarna började. Det visade sig att dbeaver, som en sann applikation, skrevs på Eclipse-plattformen med OSGi-ramverket. För erfarna utvecklare gör den här saken det bekvämt att hantera beroenden, men för mig var det mer som mörk magi, vilket jag uppenbarligen inte var redo för: som vanligt importerar jag de klasser jag behöver från json-simple-biblioteket i rubriken på den redigerade klassen, specificera den i pom.xml, varefter projektet kategoriskt vägrar att montera normalt och kraschar med fel.

Till slut lyckades jag fixa byggfelen: jag registrerade biblioteket inte i pom.xml, utan i manifest.mf manifestet, som krävs av OSGI, samtidigt som jag angav det som importpaket. Inte den vackraste lösningen, men det fungerar. Sedan dök nästa överraskning upp. Om du utvecklar i Intellij Idea kan du inte bara gå och börja felsöka ditt projekt baserat på eclipse-plattformen: en oerfaren utvecklare borde lida inte mindre än en analytiker utan att en fråga har slutförts. Bäverutvecklarna kom själva till undsättning och angav i wikin alla danser med en tamburin som måste göras. Det mest irriterande är att även efter alla dessa knäböj ville projektet inte lanseras i debug med json-biblioteket anslutet via importpaket (trots att det fortfarande lyckades monteras ihop till den färdiga produkten).

Vid den tiden hade jag redan insett besväret med att använda json för min uppgift - trots allt var det meningen att metadata skulle redigeras manuellt, och xml-formatet är bättre lämpat för detta. Det andra argumentet för xml var närvaron av alla nödvändiga klasser i JDK, vilket gjorde det möjligt att sluta slåss med ett externt bibliotek. Med stor glädje överförde jag all metadata från json till xml och började redigera autokompletteringslogiken.

Exempel på metadata

<?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>

Som ett resultat jag gjort ändringar i klasserna SQLUtils och SQLCompletionAnalyzer. Tanken är denna: om programmet inte kunde hitta lämpliga autokompletteringsförslag med den grundläggande logiken, kontrollerar det om det finns möjliga anslutningar med hjälp av en extern xml-fil. Själva filen lagrar tabellpar som anger de fält som dessa tabeller behöver länkas till. Restriktioner för de tekniska giltighetsdatumen för poster eff_dttm och exp_dttm och den logiska borttagningsflaggan deleted_ind är inställda som standard.

När ändringar gjordes i koden uppstod frågan – vem ska fylla filen med metadata? Det finns många enheter i förvaret, det är dyrt att registrera alla anslutningar själv. Som ett resultat bestämde jag mig för att tilldela mina analytikerkollegor denna uppgift. Jag lade upp metadatafilen i svn, varifrån en utcheckning görs till den lokala katalogen med programmet. Principen är denna: har en ny enhet dykt upp i förvaret? En analytiker lägger in möjliga anslutningar till filen, gör ändringar, resten checkar ut för sig själva och njuter av den fungerande autokompletteringen: gemenskap, ackumulering av kunskap och allt det där. Genomförde en workshop om att använda programmet för kollegor, skrev en artikel i Confluence - nu har företaget ett mer praktiskt verktyg.

Att arbeta med den här funktionen gav mig förståelsen att det inte finns något behov av att vara rädd för att mixtra med projekt med öppen källkod - som regel har de en tydlig arkitektur, och till och med grundläggande kunskaper om språket kommer att räcka för experiment. Och med en viss uthållighet kommer du till och med att kunna bli av med hatade rutinoperationer, vilket sparar dig tid för nya experiment.

Källa: will.com