🥇Come smettere di fare sempre la stessa cosa

Ti piace ripetere di volta in volta operazioni di routine? A me no. Ma ogni volta che lavoro con il client SQL sul repository di Rostelecom dovevo digitare a mano tutte le join tra le tabelle. E questo nonostante nel 90% dei casi i campi e le condizioni di join delle tabelle coincidessero da una query all'altra! Sembrerebbe che qualsiasi client SQL abbia funzioni di completamento automatico, ma per i repository non sempre funziona: di solito non vengono impostati unique constraint e foreign key per migliorare le prestazioni, e senza di essi il programma non sa come sono collegate le entità e cosa può offrirti.

Dopo aver attraversato la negazione, la rabbia, le trattative, la depressione e avvicinandomi all'accettazione, ho deciso: perché non provare a implementare io stesso il completamento automatico con blackjack e tutto il resto? Utilizzo il client dbeaver, scritto in java, che ha una versione community con codice sorgente aperto. È nato un semplice piano:

Trovare nel codice sorgente le classi responsabili del completamento automatico
Riorientarle per lavorare con metadati esterni e prelevare da lì informazioni sulle join
??????
PROFITTO

Sono riuscito a chiarire rapidamente il primo punto: ho trovato nel bug tracker una richiesta di correzione del completamento automatico e nel relativo commit ho scoperto la classe SQLCompletionAnalyzer. Ho guardato il codice: era proprio quello che mi serviva. Dovevo solo riscriverlo affinché funzionasse. Ho atteso una serata libera e ho iniziato a progettare l'implementazione. Ho deciso di mantenere le regole di relazione tra le tabelle (metadati) in formato json. Non avevo esperienza pratica con questo formato e il compito attuale sembrava l'occasione giusta per colmare questa lacuna.

Per lavorare con json ho deciso di utilizzare la libreria json-simple di Google. Qui sono iniziate le sorprese. Come si è scoperto, dbeaver, come vero e proprio applicativo, è scritto sulla piattaforma Eclipse utilizzando il framework OSGi. Per i programmatori esperti questa cosa offre un'agevole gestione delle dipendenze, ma per me sembrava più simile a magia nera, alla quale non ero affatto pronto: come al solito importo le classi di cui ho bisogno dalla libreria json-simple all'inizio della classe che sto modificando, la indico in pom.xml, dopo di ché il progetto si rifiuta categoricamente di compilarsi correttamente e cade con errori.

Correggere gli errori di assemblaggio alla fine è stato possibile: ho registrato la libreria non nel pom.xml, ma nel manifesto manifest.mf, come richiede OSGI, specificandola come import-package. Non è la soluzione più elegante, ma funziona. È emersa una sorpresa successiva. Se stai sviluppando in IntelliJ IDEA, non puoi semplicemente avviare il debug del tuo progetto basato su Eclipse: un sviluppatore inesperto deve soffrire non meno di un analista senza completamento automatico delle query. I stessi sviluppatori di Beavers sono venuti in aiuto, indicando nella wiki tutte le danze necessarie da fare. La cosa più frustrante è che anche dopo tutti questi stravolgimenti, il progetto non voleva avviarsi in debug con la libreria JSON importata tramite import-package (anche se, nella versione finale, si compilava comunque con successo).

A quel punto, avevo già avvertito l'inconveniente nell'utilizzo di JSON per il mio compito: era comunque previsto che i metadati venissero modificati manualmente, e per questo il formato XML si adatta meglio. Un secondo argomento a favore dell'XML era la presenza di tutte le classi necessarie nell'JDK, il che ha permesso di interrompere la lotta con la libreria esterna. Con grande piacere, ho trasferito tutti i metadati da JSON a XML e ho iniziato a modificare la logica del completamento automatico.

Esempio di metadati

dim_account
        dim_partner
        
        
    
    
        dim_account
        dim_branch

Di conseguenza ho apportato modifiche alle classi SQLUtils e SQLCompletionAnalyzer. L'idea è questa: se il programma non riesce a trovare suggerimenti di completamento automatico secondo la logica di base, allora verifica la presenza di possibili join attraverso un file XML esterno. Nel file stesso sono memorizzate coppie di tabelle con l'indicazione dei campi attraverso cui queste tabelle devono essere collegate. Le restrizioni sulle date tecniche di validità dei record eff_dttm ed exp_dttm e il flag di cancellazione logica deleted_ind sono impostati di default.

Quando sono state apportate le modifiche al codice, è emersa la domanda: chi si occuperà di compilare il file con i metadati? Ci sono molte entità nel deposito e sarebbe complicato definire manualmente tutte le relazioni. Alla fine, ho deciso di assegnare questo compito ai miei colleghi analisti. Ho caricato il file dei metadati in svn, da dove viene effettuato il checkout nella directory locale con il programma. Il principio è questo: è stata aggiunta una nuova entità nel deposito? Un analista inserisce i possibili join nel file, effettua il commit delle modifiche, gli altri fanno il checkout e si godono il riempimento automatico funzionante: comunità, accumulo di conoscenze e tutto il resto. Ho tenuto un workshop per i colleghi sull'uso del programma e ho scritto un articolo in Confluence: ora in azienda c'è uno strumento in più che semplifica il lavoro.

L'esperienza su questa funzionalità mi ha fatto capire che non bisogna avere paura di esplorare progetti open source: di solito hanno un'architettura comprensibile e anche conoscenze di base del linguaggio sono sufficienti per fare esperimenti. Con una certa dose di perseveranza, si può anche riuscire a eliminare quelle fastidiose operazioni routinarie, risparmiando tempo per nuovi esperimenti.

Fonte: habr.com