Hoe te stoppen met hetzelfde steeds opnieuw te doen

Houdt u ervan om keer op keer routinematige handelingen te herhalen? Ik in ieder geval niet. Maar elke keer dat ik met de opslag van Rostelecom werkte in een SQL-client, moest ik al de joins tussen de tabellen handmatig invoeren. En dat terwijl in 90% van de gevallen de velden en de voorwaarden voor het verbinden van tabellen van query tot query overeenkwamen! Het zou logisch zijn dat iedere SQL-client auto-completion functies heeft, maar voor opslag werkt dat niet altijd: ze hebben zelden unieke constraints en foreign keys om de prestaties te verbeteren, en zonder dat weet het programma niet hoe de entiteiten met elkaar verbonden zijn en wat het je kan aanbieden.

Na het doorlopen van ontkenning, woede, onderhandelingen, depressie en het naderen van acceptatie, besloot ik - waarom zou ik het zelf niet proberen om auto-completion te implementeren, met blackjack en alles erop en eraan? Ik gebruik de client dbeaver, geschreven in Java, die een communityversie heeft met open source. Ik had een eenvoudig plan bedacht:

1. Zoek in de broncode naar de klassen die verantwoordelijk zijn voor auto-completion
2. Herschrijf ze om met externe metadata te werken en trek informatie over de joins daarvan aan
3. ??????
4. PROFIT

Met het eerste punt ben ik vrij snel klaar geweest - ik vond in de bugtracker een verzoek om de auto-completion te verbeteren en in de bijbehorende commit ontdekte ik de klasse SQLCompletionAnalyzer. Ik bekeek de code - precies wat ik nodig had. Het enige wat overbleef was het herschrijven zodat alles werkte. Ik wachtte op een vrije avond en begon na te denken over de implementatie. De regels voor tabelrelaties (metadata) besloot ik in json te beheren. Ik had geen praktische ervaring met dit formaat en de huidige taak leek een kans om deze tekortkoming te verhelpen.

Voor het werken met json besloot ik de bibliotheek json-simple van Google te gebruiken. Hier begonnen de verrassingen. Het bleek dat dbeaver, als een echt applicatie, op het Eclipse-platform is geschreven met gebruik van het OSGi-framework. Voor ervaren ontwikkelaars biedt dit gemak in het beheer van afhankelijkheden, voor mij leek het echter meer op zwarte magie, waarvoor ik duidelijk niet voorbereid was: zoals gewoonlijk schrijf ik imports van de benodigde klassen uit de json-simple bibliotheek bovenaan de te bewerken klasse, geef ik ze op in pom.xml, waarna het project categorisch weigert om correct te compileren en met fouten faalt.

De fouten bij het bouwen zijn uiteindelijk opgelost: ik heb de bibliotheek niet in pom.xml, maar in het manifest manifest.mf vermeld, zoals vereist door OSGI, waarbij ik deze als import-package heb aangegeven. Het is misschien niet de mooiste oplossing, maar het werkt wel. Toen kwam de volgende verrassing. Als je ontwikkelt in IntelliJ IDEA, kun je niet zomaar je project dat op het Eclipse-platform is gebaseerd, debuggen: een onervaren ontwikkelaar moet net zoveel lijden als een analist zonder autocompletion van queries. De ontwikkelaars van Beaver hebben ons geholpen door in de wiki alle stappen te beschrijven die moeten worden doorlopen. Het meest frustrerende was dat zelfs na al deze inspanningen het project niet in debugmodus wilde draaien met de via import-package aangesloten json-bibliotheek (terwijl het in het eindproduct nog steeds succesvol gebouwd werd).

Tegen die tijd had ik het ongemak van het gebruik van json voor mijn taak goed ervaren - de metadata moest immers handmatig worden bewerkt, en voor dit doel past het xml-formaat beter. Een tweede argument voor xml was dat alle noodzakelijke klassen in de JDK aanwezig waren, wat ons in staat stelde de strijd met de externe bibliotheek te beëindigen. Met veel plezier heb ik alle metadata van json naar xml overgezet en ben ik begonnen met het aanpassen van de logica voor autocompletion.

Voorbeeld van metadata

dim_account
        dim_partner
        
        
    
    
        dim_account
        dim_branch

Als resultaat heb ik wijzigingen aangebracht in de klassen SQLUtils en SQLCompletionAnalyzer. Het idee is als volgt: als de applicatie er niet in slaagt om geschikte autocompletionvoorstellen te vinden op basis van de basislogica, controleert ze of er mogelijke joins zijn via een extern xml-bestand. In het bestand worden tabelparen opgeslagen met de velden die aangeven hoe deze tabellen moeten worden gekoppeld. Beperkingen op de technische datums van de actie-records eff_dttm en exp_dttm en de vlag voor logische verwijdering deleted_ind worden standaard ingesteld.

Toen de aanpassingen in de code waren doorgevoerd, ontstond de vraag — wie gaat het metadata-bestand invullen? Er zijn veel entiteiten in de opslag, en het zelf handmatig vastleggen van alle relaties is te veel werk. Uiteindelijk besloot ik deze taak aan mijn collega-analisten te geven. Het metadata-bestand heb ik in svn geplaatst, van waaruit een checkout naar de lokale map met het programma wordt gemaakt. Het principe is als volgt: er verschijnt een nieuwe entiteit in de opslag? Eén analist voegt mogelijke joins toe aan het bestand, commit de wijzigingen, de anderen doen een checkout naar hun eigen omgeving en genieten van de automatische aanvulling: een community, kennisopbouw en dergelijke. Ik heb een workshop voor mijn collega's georganiseerd over het gebruik van het programma en een artikel geschreven in Confluence — nu hebben we in het bedrijf weer een handig hulpmiddel erbij.

Het werken aan deze functie heeft me doen beseffen dat je niet bang moet zijn om open-source projecten te verkennen — over het algemeen hebben ze een duidelijke architectuur, en zelfs basiskennis van de taal is meestal voldoende voor experimenten. Met een bepaalde mate van volharding kun je zelfs die vervelende routinematige taken vermijden en tijd besparen voor nieuwe experimenten.

Bron: habr.com