Hur slutar man att göra samma sak om och om igen

Älskar du att upprepa rutinoperationer gång på gång? Det gör inte jag. Men varje gång jag arbetade med Rosetelecoms datalager i SQL-klienten var jag tvungen att manuellt ange alla joins mellan tabeller. Och detta trots att i 90 % av fallen fälten och villkoren för att förena tabellerna stämde överens från fråga till fråga! Det skulle kännas som att vilken SQL-klient som helst har autocompletionsfunktioner, men för datalager fungerar det inte alltid: där sällan skapas unique constraint och foreign key för att öka prestanda, och utan det kan programmet inte förstå hur entiteterna hänger ihop och vad det kan erbjuda dig.

Efter att ha gått igenom förnekelse, ilska, förhandlande, depression och närmande till acceptans, bestämde jag mig - varför inte försöka implementera autocompletion själv med lite blackjack som man ska? Jag använder klienten dbeaver, skriven i java, och den har en community-version med öppen källkod. Jag kom på en enkel plan:

1. Hitta klasserna i källkoden som ansvarar för autocompletion
2. Omrikta dem för att arbeta med externa metadata och hämta information om joins därifrån
3. ??????
4. PROFIT

Jag kom snabbt fram till den första punkten - jag hittade i bugtrackern en begäran om att justera autocompletion och i relaterad commit upptäckte jag klassen SQLCompletionAnalyzer. Jag tittade på koden - precis vad jag behövde. Nu återstod det bara att skriva om den så att allt fungera. Jag väntade på en ledig kväll och började planera implementationen. Reglerna för tabellrelationer (metadata) bestämde jag mig för att spara i json. Jag hade ingen praktisk erfarenhet av att arbeta med detta format och den aktuella uppgiften verkade vara en möjlighet att åtgärda denna brist.

För att arbeta med json bestämde jag mig för att använda biblioteket json-simple från Google. Här började överraskningarna. Som det visade sig är dbeaver, som ett äkta program, skrivet på eclipse-plattformen med hjälp av OSGi-ramverket. För erfarna utvecklare ger detta bekvämlighet för att hantera beroenden, för mig liknade det mer mörk magi, som jag uppenbarligen inte var beredd på: vanligtvis skriver jag importen av de klasser jag behöver från biblioteket json-simple i toppen av den redigerade klassen, anger det i pom.xml, efter vilket projektet kategoriskt vägrar att byggas ordentligt och kraschar med fel.

Att åtgärda byggfel resulterade i att jag skrev in biblioteket inte i pom.xml, utan i manifestet manifest.mf, som OSGI föreskriver, och angav det som import-package. Inte den vackraste lösningen, men den fungerar. Här dök nästa överraskning upp. Om du utvecklar i IntelliJ IDEA kan du inte bara starta debuggern för ditt projekt som är baserat på Eclipse-plattformen: en oerfaren utvecklare måste lida lika mycket som en analytiker utan autocompletion av sina frågor. Till hjälp kom själva utvecklarna av Beaver, som angav i wikin alla de danser som måste utföras. Det mest frustrerande var att även efter alla dessa ansträngningar vägrade projektet att starta i debuggern med det importerade json-biblioteket (trots att det fortfarande byggdes framgångsrikt i det färdiga produkten).

Vid den tiden hade jag upplevt obehaget med att använda json för min uppgift — metadata var tänkt att redigeras manuellt, och för det passar xml-formatet bättre. Det andra argumentet för xml var att JDK hade alla nödvändiga klasser, vilket gjorde att jag kunde sluta kämpa med det externa biblioteket. Jag flyttade med stor glädje all metadata från json till xml och började arbeta med logiken för autocompletion.

Exempel på metadata

dim_account
        dim_partner
        
        
    
    
        dim_account
        dim_branch

Som ett resultat av detta gjorde jag ändringar i klasserna SQLUtils och SQLCompletionAnalyzer. Idén är följande: om programmet inte lyckas föreslå lämpliga autocompletion-förslag enligt grundlogiken, kontrollerar det om det finns möjliga joins enligt filen xml. I själva filen lagras tabell-par med angivande av fält som dessa tabeller ska kopplas samman med. Begränsningar för tekniska datumen för poster eff_dttm och exp_dttm och flaggan för logisk borttagning deleted_ind anges som standard.

När ändringarna i koden hade gjorts uppstod frågan — vem kommer att fylla i metadatafilen? Det finns många entiteter i lagret, att skriva alla kopplingar själv blir tungt. I slutändan beslutade jag att ge denna uppgift till mina kollegor inom analys. Metadatafilen lade jag ut i svn, därifrån görs en checkout i den lokala katalogen med programmet. Principen är följande: har en ny entitet lagts till i lagret? En analytiker lägger in möjliga joins i filen, committar ändringarna, de andra gör checkout till sig och njuter av det fungerande autofyllandet: community, kunskapsuppbyggnad och allt sånt. Jag höll en workshop för kollegorna om användning av programmet, skrev en artikel i Confluence — nu har företaget ett bekvämare verktyg.

Arbetet med denna funktion gav mig insikten att man inte ska vara rädd för att peta i open source-projekt — som regel har de en tydlig arkitektur, och även grundläggande kunskaper i språket räcker för experiment. Med en viss grad av envishet kan man till och med bli av med de hatade rutinoperationerna och spara tid för nya experiment.

Källa: habr.com