Ti piace ripetere le operazioni di routine più e più volte? Quindi non lo faccio. Ma ogni volta che lavoravo con lo spazio di archiviazione Rostelecom nel client SQL, dovevo registrare manualmente tutti i join tra le tabelle. E questo nonostante nel 90% dei casi i campi e le condizioni per l'unione dei tavoli coincidessero da richiesta a richiesta! Sembrerebbe che qualsiasi client SQL abbia funzioni di completamento automatico, ma per gli archivi non sempre funziona: raramente includono vincoli univoci e chiave esterna per migliorare le prestazioni, e senza di ciò il programma non saprà come sono correlate le entità a ciascuna altro e cosa può fare per te.
Dopo aver attraversato la negazione, la rabbia, la contrattazione, la depressione e l'avvicinarsi all'accettazione, ho deciso: perché non provare a implementare io stesso il riempimento automatico con il blackjack e farlo nel modo giusto? Utilizzo il client dbeaver, scritto in Java, ha una versione community open source. È maturato un piano semplice:
- Trova le classi nel codice sorgente responsabili del completamento automatico
- Reindirizzarli per lavorare con metadati esterni e estrarre informazioni sui join da lì
- ??????
- UTILE
Ho capito il primo punto abbastanza velocemente: ho trovato una richiesta nel bug tracker per regolare il riempimento automatico e nel relativo scoperto la classe SQLCompletionAnalyzer. Ho guardato il codice ed è quello che mi serve. Non resta che riscriverlo affinché tutto funzioni. Ho aspettato una serata libera e ho iniziato a pensare all'implementazione. Ho deciso di scrivere le regole di collegamento della tabella (metadati) in json. Non avevo esperienza pratica di lavoro con questo formato e il compito attuale è stato visto come un'opportunità per correggere questa omissione.
Per lavorare con json ho deciso di utilizzare la libreria da Google. È qui che sono iniziate le sorprese. Come si è scoperto, dbeaver, come una vera applicazione, è stata scritta sulla piattaforma Eclipse utilizzando il framework OSGi. Per gli sviluppatori esperti questa cosa rende conveniente la gestione delle dipendenze, ma per me è stata più una magia oscura, per la quale evidentemente non ero pronto: come al solito importo le classi che mi servono dalla libreria json-simple nell'header di la classe modificata, specificarla nel pom.xml, dopodiché il progetto rifiuta categoricamente di assemblarsi normalmente e si blocca con errori.
Alla fine, sono riuscito a correggere gli errori di compilazione: ho registrato la libreria non in pom.xml, ma nel manifest manifest.mf, come richiesto da OSGI, specificandolo come pacchetto di importazione. Non è la soluzione più bella, ma funziona. Poi è apparsa la sorpresa successiva. Se stai sviluppando in Intellij Idea, non puoi semplicemente iniziare a eseguire il debug del tuo progetto basato sulla piattaforma Eclipse: uno sviluppatore inesperto dovrebbe soffrire non meno di un analista senza il completamento della query. Gli stessi sviluppatori di Beaver sono venuti in soccorso, indicando nella wiki tutti i balli con un tamburello che devono essere eseguiti. La cosa più fastidiosa è che anche dopo tutti questi squat, il progetto non ha voluto essere lanciato in debug con la libreria json collegata tramite import-package (nonostante fosse comunque assemblata con successo nel prodotto finito).
A quel punto, mi ero già reso conto dell'inconveniente di utilizzare JSON per il mio compito: dopo tutto, i metadati avrebbero dovuto essere modificati manualmente e il formato xml è più adatto a questo. Il secondo argomento a favore di xml è stata la presenza di tutte le classi necessarie nel JDK, che ha permesso di smettere di litigare con una libreria esterna. Con grande piacere ho trasferito tutti i metadati da json a xml e ho iniziato a modificare la logica di completamento automatico.
Esempio di metadati
<?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>Di conseguenza io nelle classi SQLUtils e SQLCompletionAnalyzer. L'idea è questa: se il programma non riesce a trovare suggerimenti di completamento automatico adeguati utilizzando la logica di base, verifica la presenza di possibili unioni utilizzando un file xml esterno. Il file stesso memorizza coppie di tabelle che indicano i campi in base ai quali queste tabelle devono essere collegate. Le restrizioni sulle date di validità tecnica dei record eff_dttm e exp_dttm e il flag di cancellazione logica delete_ind sono impostati per impostazione predefinita.
Quando sono state apportate modifiche al codice, è sorta la domanda: chi riempirà il file con i metadati? Ci sono molte entità nel repository, è costoso registrare tu stesso tutte le connessioni. Di conseguenza, ho deciso di affidare questo compito ai miei colleghi analisti. Ho pubblicato il file di metadati in svn, da dove viene effettuato il checkout nella directory locale con il programma. Il principio è questo: è apparsa una nuova entità nel repository? Un analista inserisce possibili join nel file, conferma le modifiche, gli altri controllano da soli e si godono il completamento automatico del lavoro: comunità, accumulo di conoscenza e tutto il resto. Ho condotto un seminario sull'utilizzo del programma per i colleghi, ho scritto un articolo su Confluence: ora l'azienda dispone di uno strumento più conveniente.
Lavorare su questa funzionalità mi ha fatto capire che non c'è bisogno di aver paura di armeggiare con progetti open source: di regola hanno un'architettura chiara e anche la conoscenza di base della lingua sarà sufficiente per gli esperimenti. E con una certa perseveranza, sarai anche in grado di sbarazzarti delle odiate operazioni di routine, risparmiando tempo per nuovi esperimenti.
Fonte: habr.com