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:
- Finn klasser i kildekoden som er ansvarlige for autofullføring
- Omdiriger dem til å jobbe med eksterne metadata og hente informasjon om sammenføyninger derfra
- ???
- RESULTAT
Jeg fant ut det første punktet ganske raskt - jeg fant en forespørsel i feilsporeren om å justere autofyllingen og i den relaterte
For å jobbe med json bestemte jeg meg for å bruke biblioteket
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
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