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:
- Zoek klassen in de broncode die verantwoordelijk zijn voor automatisch aanvullen
- Stuur ze door om met externe metadata te werken en haal daar informatie over joins op
- ???
- 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
Om met json te werken, besloot ik de bibliotheek te gebruiken
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
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