Kan du lide at gentage rutineoperationer igen og igen? Så det gør jeg ikke. Men hver gang i SQL-klienten, når jeg arbejdede med Rostelecom-lageret, skulle jeg registrere alle joins mellem tabellerne manuelt. Og dette til trods for, at felterne og betingelserne for at deltage i borde i 90 % af tilfældene faldt sammen fra anmodning til anmodning! Det ser ud til, at enhver SQL-klient har autofuldførelsesfunktioner, men for lager fungerer det ikke altid: de indeholder sjældent unikke begrænsninger og fremmednøgle for at forbedre ydeevnen, og uden dette vil programmet ikke vide, hvordan entiteter er relateret til hver andet og hvad det kan gøre for dig at tilbyde.
Efter at have været igennem benægtelse, vrede, forhandlinger, depression og nærmer mig accept, besluttede jeg - hvorfor ikke prøve at implementere autofill med blackjack selv og gøre det på den rigtige måde? Jeg bruger dbeaver-klienten, skrevet i java, den har en open source-fællesskabsversion. En simpel plan er modnet:
- Find klasser i kildekoden, der er ansvarlige for autofuldførelse
- Omdiriger dem til at arbejde med eksterne metadata og trække oplysninger om joins derfra
- ??????
- PROFIT
Jeg fandt ud af det første punkt ret hurtigt - jeg fandt en anmodning i fejlsporingen om at justere autofyld og i den relaterede
For at arbejde med json besluttede jeg at bruge biblioteket
Til sidst lykkedes det mig at rette opbygningsfejlene: Jeg registrerede biblioteket ikke i pom.xml, men i manifest.mf manifestet, som krævet af OSGI, mens jeg specificerede det som import-pakke. Ikke den smukkeste løsning, men det virker. Så dukkede den næste overraskelse op. Hvis du udvikler i Intellij Idea, kan du ikke bare gå og begynde at fejlfinde dit projekt baseret på eclipse-platformen: en uerfaren udvikler bør lide ikke mindre end en analytiker uden forespørgselsfuldførelse. Bæverudviklerne kom selv til undsætning og angav i wikien alle danse med en tamburin, der skal laves. Det mest irriterende er, at selv efter alle disse squats, ønskede projektet ikke at blive lanceret i debug med json-biblioteket forbundet via import-pakke (på trods af at det stadig var vellykket samlet til det færdige produkt).
På det tidspunkt havde jeg allerede indset ulejligheden ved at bruge json til min opgave - metadataene skulle jo redigeres manuelt, og xml-formatet er bedre egnet til dette. Det andet argument til fordel for xml var tilstedeværelsen af alle de nødvendige klasser i JDK, hvilket gjorde det muligt at stoppe kampene med et eksternt bibliotek. Med stor fornøjelse overførte jeg alle metadata fra json til xml og begyndte at redigere autofuldførelseslogikken.
Metadata eksempel
<?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 der blev lavet ændringer i koden, opstod spørgsmålet - hvem skal fylde filen med metadata? Der er mange enheder i depotet, det er dyrt at registrere alle forbindelserne selv. Som et resultat besluttede jeg at tildele denne opgave til mine medanalytikere. Jeg lagde metadatafilen i svn, hvorfra der foretages en checkout til den lokale mappe med programmet. Princippet er dette: Er der dukket en ny enhed op i depotet? Én analytiker indtaster mulige joinforbindelser i filen, foretager ændringer, resten tjekker ud for sig selv og nyder den fungerende autofuldførelse: fællesskab, ophobning af viden og alt det der. Gennemførte en workshop om brug af programmet for kolleger, skrev en artikel i Confluence - nu har virksomheden endnu et praktisk værktøj.
At arbejde på denne funktion gav mig forståelsen af, at der ikke er nogen grund til at være bange for at pille ved open source-projekter - som regel har de en klar arkitektur, og selv grundlæggende viden om sproget vil være nok til eksperimenter. Og med en vis portion vedholdenhed vil du endda være i stand til at slippe af med hadede rutineoperationer, hvilket sparer dig selv for tid til nye eksperimenter.
Kilde: www.habr.com