Hvordan man stopper med at gøre det samme

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:

1. Find klasser i kildekoden, der er ansvarlige for autofuldførelse
2. Omdiriger dem til at arbejde med eksterne metadata og trække oplysninger om joins derfra
3. ??????
4. 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 begå opdagede SQLCompletionAnalyzer-klassen. Jeg kiggede på koden og det er hvad jeg har brug for. Det eneste, der er tilbage, er at omskrive det, så alt fungerer. Jeg ventede på en ledig aften og begyndte at tænke implementeringen igennem. Jeg besluttede at skrive tabellinkregler (metadata) i json. Jeg havde ingen praktisk erfaring med at arbejde med dette format, og den aktuelle opgave blev set som en mulighed for at rette op på denne udeladelse.

For at arbejde med json besluttede jeg at bruge biblioteket json-simpel fra Google. Det var her, overraskelserne begyndte. Som det viste sig, blev dbeaver, som en ægte applikation, skrevet på Eclipse-platformen ved hjælp af OSGi-rammerne. For erfarne udviklere gør denne ting det praktisk at administrere afhængigheder, men for mig var det mere som mørk magi, som jeg tydeligvis ikke var klar til: Som sædvanlig importerer jeg de klasser, jeg har brug for, fra json-simple-biblioteket i overskriften på den redigerede klasse, specificer den i pom.xml, hvorefter projektet kategorisk nægter at samle normalt og crasher med fejl.

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 foretaget ændringer ind i klasserne SQLUtils og SQLCompletionAnalyzer. Ideen er denne: Hvis programmet ikke var i stand til at finde passende autofuldførelsesforslag ved hjælp af den grundlæggende logik, så kontrollerer det for tilstedeværelsen af ​​mulige joinforbindelser ved hjælp af en ekstern xml-fil. Selve filen gemmer par af tabeller, der angiver de felter, som disse tabeller skal forbindes med. Begrænsninger på de tekniske gyldighedsdatoer for poster eff_dttm og exp_dttm og det logiske sletningsflag deleted_ind er som standard indstillet.

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