Hvordan slutte å gjøre det samme

Liker du å gjenta rutineoperasjoner om og om igjen? Så det gjør jeg ikke. Men hver gang i SQL-klienten når jeg jobbet med Rostelecom-lagringen, måtte jeg registrere alle sammenføyningene mellom tabellene manuelt. Og dette til tross for at i 90 % av tilfellene falt feltene og betingelsene for å slå sammen tabeller fra forespørsel til forespørsel! Det ser ut til at enhver SQL-klient har autofullføringsfunksjoner, men for lagring fungerer det ikke alltid: de inkluderer sjelden unik begrensning og fremmednøkkel for å forbedre ytelsen, og uten dette vil ikke programmet vite hvordan enheter er relatert til hver annet og hva det kan gjøre for deg.

Etter å ha gått gjennom fornektelse, sinne, forhandlinger, depresjon og nærmer meg aksept, bestemte jeg meg - hvorfor ikke prøve å implementere autofyll med blackjack selv og gjøre det på riktig måte? Jeg bruker dbeaver-klienten, skrevet i java, den har en fellesskapsversjon med åpen kildekode. En enkel plan har modnet:

1. Finn klasser i kildekoden som er ansvarlige for autofullføring
2. Omdiriger dem til å jobbe med eksterne metadata og hente informasjon om sammenføyninger derfra
3. ???
4. RESULTAT

Jeg fant ut det første punktet ganske raskt - jeg fant en forespørsel i feilsporeren om å justere autofyllingen og i den relaterte begå oppdaget SQLCompletionAnalyzer-klassen. Jeg så på koden og det er det jeg trenger. Det gjenstår bare å skrive det om slik at alt fungerer. Jeg ventet på en ledig kveld og begynte å tenke gjennom implementeringen. Jeg bestemte meg for å skrive tabellkoblingsregler (metadata) i json. Jeg hadde ingen praktisk erfaring med å jobbe med dette formatet, og den nåværende oppgaven ble sett på som en mulighet til å rette opp denne utelatelsen.

For å jobbe med json bestemte jeg meg for å bruke biblioteket json-enkel fra Google. Det var her overraskelsene begynte. Som det viste seg, ble dbeaver, som en ekte applikasjon, skrevet på Eclipse-plattformen ved å bruke OSGi-rammeverket. For erfarne utviklere gjør denne tingen det praktisk å administrere avhengigheter, men for meg var det mer som mørk magi, som jeg tydeligvis ikke var klar for: Som vanlig importerer jeg klassene jeg trenger fra json-simple-biblioteket i overskriften til den redigerte klassen, spesifiser den i pom.xml, hvoretter prosjektet kategorisk nekter å sette sammen normalt og krasjer med feil.

Til slutt klarte jeg å fikse byggefeilene: Jeg registrerte ikke biblioteket i pom.xml, men i manifest.mf-manifestet, som kreves av OSGI, mens jeg spesifiserte det som import-pakke. Ikke den vakreste løsningen, men den fungerer. Så dukket neste overraskelse opp. Hvis du utvikler i Intellij Idea, kan du ikke bare begynne å feilsøke prosjektet ditt basert på eclipse-plattformen: en uerfaren utvikler bør lide ikke mindre enn en analytiker uten fullføring av spørringen. Beverutviklerne selv kom til unnsetning, og indikerte i wikien alle dansene med en tamburin som må gjøres. Det mest irriterende er at selv etter alle disse knebøyene, ønsket ikke prosjektet å bli lansert i feilsøking med json-biblioteket tilkoblet via import-pakke (til tross for at det fortsatt var vellykket satt sammen til det ferdige produktet).

På det tidspunktet hadde jeg allerede innsett ulempen med å bruke json til oppgaven min – tross alt skulle metadataene redigeres manuelt, og xml-formatet er bedre egnet for dette. Det andre argumentet for xml var tilstedeværelsen av alle de nødvendige klassene i JDK, som gjorde det mulig å slutte å slåss med et eksternt bibliotek. Med stor glede overførte jeg alle metadataene fra json til xml og begynte å redigere autofullføringslogikken.

Eksempel 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 et resultat jeg gjort endringer inn i klassene SQLUtils og SQLCompletionAnalyzer. Ideen er denne: hvis programmet ikke var i stand til å finne passende autofullføringsforslag ved å bruke den grunnleggende logikken, sjekker det for tilstedeværelsen av mulige sammenføyninger ved hjelp av en ekstern xml-fil. Selve filen lagrer tabellpar som indikerer feltene som disse tabellene må kobles til. Restriksjoner på de tekniske gyldighetsdatoene for postene eff_dttm og exp_dttm og det logiske sletteflagget deleted_ind er satt som standard.

Da det ble gjort endringer i koden, dukket spørsmålet opp – hvem skal fylle filen med metadata? Det er mange enheter i depotet, det er dyrt å registrere alle tilkoblingene selv. Som et resultat bestemte jeg meg for å tildele denne oppgaven til mine medanalytikere. Jeg la ut metadatafilen i svn, hvorfra det gjøres en utsjekking til den lokale katalogen med programmet. Prinsippet er dette: har en ny enhet dukket opp i depotet? Én analytiker legger inn mulige sammenføyninger i filen, forplikter endringer, resten sjekker ut for seg selv og nyter den fungerende autofullføringen: fellesskap, akkumulering av kunnskap og alt det der. Gjennomførte en workshop om bruk av programmet for kolleger, skrev en artikkel i Confluence - nå har selskapet enda et praktisk verktøy.

Arbeidet med denne funksjonen ga meg forståelsen av at det ikke er nødvendig å være redd for å fikle med åpen kildekode-prosjekter - som regel har de en klar arkitektur, og til og med grunnleggende kunnskap om språket vil være nok for eksperimenter. Og med en viss utholdenhet vil du til og med kunne bli kvitt forhatte rutineoperasjoner, og spare deg selv for tid til nye eksperimenter.

Kilde: www.habr.com