Hvordan man stopper med at gøre det samme om og om igen

Elsker du at gentage rutineopgaver igen og igen? Det gør jeg ikke. Men hver gang jeg arbejder med RusTelecoms lager i SQL-klienten, må jeg manuelt skrive alle joins mellem tabellerne. Og det på trods af, at i 90% af tilfældene, felterne og betingelserne for at sammenkoble tabellerne stemmer overens fra forespørgsel til forespørgsel! Man skulle tro, at enhver SQL-klient har autofyldningsfunktioner, men det virker ikke altid for lagre: der oprettes sjældent unique constraint og foreign key for at forbedre ydeevnen, og uden dette kan programmet ikke vide, hvordan entiteterne hænger sammen, og hvad det kan tilbyde dig.

Efter at have gennemgået fornektelse, vrede, forhandling, depression og nærmet mig accept, besluttede jeg - hvorfor ikke prøve at implementere autofyldning med blackjack og det hele? Jeg bruger klienten dbeaver, som er skrevet i Java; den har en community-version med open source. Jeg fik en simpel plan:

1. Find klasserne i kildekoden, der ansvarlig for autofyldning.
2. Omdirigere dem til at arbejde med eksterne metadata og hente oplysninger om joins derfra.
3. ??????
4. PROFIT

Jeg kom hurtigt igennem første punkt - jeg fandt en anmodning i bugtracker om at korrigere autofyldningen og i den relaterede commit opdagede jeg klassen SQLCompletionAnalyzer. Jeg så på koden - lige hvad jeg havde brug for. Det resterende var at omskrive den, så alt virkede. Jeg ventede på en fri aften og begyndte at planlægge implementeringen. Jeg besluttede at føre reglerne for tabellers relationer (metadata) i json. Jeg havde ikke praktisk erfaring med dette format, og den aktuelle opgave så ud til at være en mulighed for at rette denne mangel.

Til arbejde med json besluttede jeg at bruge biblioteket json-simple fra Google. Her begyndte overraskelserne. Som det viste sig, er dbeaver som en ægte applikation skrevet på Eclipse-platformen med brug af OSGi-rammen. For erfarne udviklere giver denne ting nemhed i administrationsafhængigheder; for mig virkede det mere som sort magi, som jeg åbenlyst ikke var klar til: som sædvanligt skrev jeg importen af de klasser, jeg havde brug for fra json-simple biblioteket i hovedet af den redigerede klasse, og angav det i pom.xml, hvorefter projektet kategorisk nægtede at kompilere korrekt og crashede med fejl.

At løse byggefejlene endte med, at jeg skrev biblioteket ikke i pom.xml, men i manifestet manifest.mf, som krævet af OSGI, og angav det som import-package. Ikke den smukkeste løsning, men den virker. Her kom der en ny overraskelse. Hvis du udvikler i IntelliJ IDEA, kan du ikke bare tage og køre debug af dit projekt, der er baseret på Eclipse-platformen: en uerfaren udvikler skal lide lige så meget som en analytiker uden autoudfyldning af forespørgsler. Heldigvis kom udviklerne hos Beavers til hjælp, idet de angav i wiki'en alle de danse, man skal udføre. Det mest ærgerlige er, at selv efter alt dette arbejde ville projektet ikke starte i debug med det tilsluttede bibliotek json via import-package (selvom det stadig blev bygget successfully i det færdige produkt).

På det tidspunkt havde jeg fået fornemmelsen af, at det var besværligt at bruge json til min opgave — trods alt skulle metadata redigeres manuelt, og til det ville xml-formatet være bedre. Det andet argument for xml var, at alle de nødvendige klasser findes i JDK, hvilket gjorde det muligt at stoppe kampen med et eksternt bibliotek. Jeg flyttede med stor fornøjelse alle metadata fra json til xml og begyndte at ændre på logikken for autoudfyldning.

Eksempel på metadata

dim_account
        dim_partner
        
        
    
    
        dim_account
        dim_branch

Som resultat har jeg foretaget ændringer i klasserne SQLUtils og SQLCompletionAnalyzer. Ideen er denne: hvis programmet ikke kunne finde passende autoudfyldningsforslag baseret på den grundlæggende logik, tjekker det for mulige joins via en ekstern xml-fil. I selve filen opbevares tabelpar med angivelse af felterne, som disse tabeller skal forbindes via. Begrænsninger på teknisk gyldighedsdata eff_dttm og exp_dttm samt flag for logisk sletning deleted_ind indstilles som standard.

Da ændringerne i koden var foretaget, opstod spørgsmålet — hvem skal udfylde metadatafilen? Der er mange enheder i databasen, og det ville være besværligt selv at angive alle relationer. Jeg besluttede derfor at overlade denne opgave til mine analytikerkolleger. Metadatafilen blev lagt i svn, hvorfra der tages checkout til den lokale mappe med programmet. Princippet er som følger: Er der en ny enhed i databasen? Én analytiker tilføjer de mulige joins til filen, committer ændringerne, og de øvrige laver checkout til sig selv og nyder det fungerende autofuldførelse: community, videnakkumulering og alt det der. Jeg holdt et workshop for kollegerne om brugen af programmet og skrev en artikel i Confluence — nu har virksomheden endnu et praktisk værktøj.

Arbejdet med denne funktion gav mig forståelse af, at man ikke skal være bange for at pille ved open source-projekter — som regel har de en overskuelig arkitektur, og selv grundlæggende sprogkundskaber er tilstrækkelige til eksperimenter. Med en vis portion vilje kan man endda slippe for de irriterende rutineopgaver og spare tid til nye eksperimenter.

Kilde: habr.com