Hoe je kunt stoppen met hetzelfde te doen

Vindt u het leuk om routinematige handelingen keer op keer te herhalen? Dus ik niet. Maar elke keer dat ik in de SQL-client met de Rostelecom-opslag werkte, moest ik alle joins tussen de tabellen handmatig registreren. En dit ondanks het feit dat in 90% van de gevallen de velden en voorwaarden voor het samenvoegen van tabellen van aanvraag tot aanvraag samenvielen! Het lijkt erop dat elke SQL-client functies voor automatisch aanvullen heeft, maar voor opslag werkt dit niet altijd: ze bevatten zelden unieke beperkingen en externe sleutels om de prestaties te verbeteren, en zonder deze weet het programma niet hoe entiteiten met elkaar verband houden. andere en wat het voor u kan betekenen.

Nadat ik ontkenning, woede, onderhandelen, depressie en naderende acceptatie had meegemaakt, besloot ik: waarom probeer ik niet zelf autofill met blackjack te implementeren en het op de juiste manier te doen? Ik gebruik de dbeaver-client, geschreven in Java, deze heeft een open source community-versie. Een eenvoudig plan is volwassen geworden:

1. Zoek klassen in de broncode die verantwoordelijk zijn voor automatisch aanvullen
2. Stuur ze door om met externe metadata te werken en haal daar informatie over joins op
3. ???
4. WINST

Ik ontdekte het eerste punt vrij snel: ik vond een verzoek in de bugtracker om het automatisch aanvullen aan te passen en in het gerelateerde verbinden heeft de klasse SQLCompletionAnalyzer ontdekt. Ik heb de code bekeken en dit is wat ik nodig heb. Het enige dat overblijft is het herschrijven zodat alles werkt. Ik wachtte op een vrije avond en begon na te denken over de implementatie. Ik besloot om tabellinkregels (metadata) in json te schrijven. Ik had geen praktische ervaring met het werken met dit formaat en de huidige taak werd gezien als een kans om deze omissie te corrigeren.

Om met json te werken, besloot ik de bibliotheek te gebruiken json-eenvoudig van Google. Dit is waar de verrassingen begonnen. Het bleek dat dbeaver, als een echte applicatie, op het Eclipse-platform was geschreven met behulp van het OSGi-framework. Voor ervaren ontwikkelaars maakt dit ding het gemakkelijk om afhankelijkheden te beheren, maar voor mij was het meer duistere magie, waar ik duidelijk niet klaar voor was: zoals gewoonlijk importeer ik de klassen die ik nodig heb uit de json-simple-bibliotheek in de header van de bewerkte klasse, specificeer deze in de pom.xml, waarna het project categorisch weigert normaal te assembleren en crasht met fouten.

Uiteindelijk slaagde ik erin de buildfouten te herstellen: ik registreerde de bibliotheek niet in pom.xml, maar in het manifest.mf-manifest, zoals vereist door OSGI, terwijl ik het specificeerde als importpakket. Niet de mooiste oplossing, maar het werkt. Toen verscheen de volgende verrassing. Als u zich ontwikkelt in Intellij Idea, kunt u niet zomaar beginnen met het debuggen van uw project op basis van het eclipse-platform: een onervaren ontwikkelaar zou niet minder moeten lijden dan een analist zonder dat de query is voltooid. De beverontwikkelaars kwamen zelf te hulp en gaven in de wiki alle dansen met een tamboerijn aan die gedaan moesten worden. Het meest vervelende is dat zelfs na al deze squats het project niet gelanceerd wilde worden in debug met de json-bibliotheek verbonden via een importpakket (ondanks het feit dat het nog steeds met succes tot het eindproduct was samengevoegd).

Tegen die tijd besefte ik al het ongemak van het gebruik van json voor mijn taak - de metadata moesten immers handmatig worden bewerkt, en het xml-formaat is hiervoor beter geschikt. Het tweede argument ten gunste van xml was de aanwezigheid van alle noodzakelijke klassen in de JDK, waardoor het mogelijk werd om te stoppen met vechten met een externe bibliotheek. Met veel plezier heb ik alle metadata van json naar xml overgebracht en ben ik begonnen met het bewerken van de autocomplete-logica.

Metagegevens voorbeeld

<?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>

Als gevolg hiervan heb ik wijzigingen aangebracht in de klassen SQLUtils en SQLCompletionAnalyzer. Het idee is dit: als het programma geen geschikte suggesties voor automatisch aanvullen kan vinden met behulp van de basislogica, controleert het op de aanwezigheid van mogelijke joins met behulp van een extern XML-bestand. Het bestand zelf slaat tabellenparen op die de velden aangeven waarmee deze tabellen moeten worden gekoppeld. Beperkingen op de technische geldigheidsdatums van records eff_dttm en exp_dttm en de logische verwijderingsvlag verwijderde_ind zijn standaard ingesteld.

Toen er wijzigingen in de code werden aangebracht, rees de vraag: wie gaat het bestand vullen met metadata? Er zijn veel entiteiten in de repository, het is duur om alle verbindingen zelf te registreren. Daarom heb ik besloten deze taak aan mijn collega-analisten toe te vertrouwen. Ik heb het metadatabestand in svn gepost, van waaruit met het programma wordt uitgecheckt naar de lokale map. Het principe is dit: is er een nieuwe entiteit in de repository verschenen? Eén analist voert mogelijke joins in het bestand in, voert wijzigingen door, de rest controleert zichzelf en geniet van de werkende automatische aanvulling: community, accumulatie van kennis en zo. Een workshop gegeven over het gebruik van het programma voor collega's, een artikel geschreven in Confluence - nu heeft het bedrijf nog een handige tool.

Door aan deze functie te werken, kreeg ik het inzicht dat je niet bang hoeft te zijn om aan open source-projecten te sleutelen - in de regel hebben ze een duidelijke architectuur en zelfs basiskennis van de taal zal voldoende zijn voor experimenten. En met een zekere mate van doorzettingsvermogen kun je zelfs gehate routinematige handelingen achterwege laten, waardoor je tijd bespaart voor nieuwe experimenten.

Bron: www.habr.com