Wolle jo routine operaasjes hieltyd wer werhelje? Dat doch ik net. Mar elke kear yn 'e SQL-client doe't ik wurke mei de opslach fan Rostelecom, moast ik alle joins tusken de tabellen manuell registrearje. En dit nettsjinsteande it feit dat yn 90% fan 'e gefallen de fjilden en betingsten foar it oanfreegjen fan tafels oerienkomme fan fersyk nei fersyk! It liket derop dat elke SQL-kliïnt funksjes foar automatyske foltôging hat, mar foar opslach wurket it net altyd: se befetsje selden unike beheining en frjemde kaai om prestaasjes te ferbetterjen, en sûnder dit sil it programma net witte hoe't entiteiten relatearre binne oan elk oare en wat it kin dwaan foar jo oanbiede.
Nei't ik troch ûntkenning, lilkens, ûnderhanneljen, depresje en it benaderjen fan akseptaasje gien, besleat ik - wêrom net besykje autofill mei blackjack sels te ymplementearjen en it op 'e goede manier te dwaan? Ik brûk de dbeaver-kliïnt, skreaun yn java, it hat in iepen boarne-mienskipferzje. In ienfâldich plan is matured:
- Fyn klassen yn 'e boarnekoade dy't ferantwurdlik binne foar autofoltôging
- Redirect se om te wurkjen mei eksterne metadata en lûke ynformaasje oer joins dêrwei
- ??????
- WINST
Ik fûn it earste punt frij fluch - ik fûn in fersyk yn 'e bug tracker om de autofill oan te passen en yn' e relatearre ûntduts de klasse SQLCompletionAnalyzer. Ik seach nei de koade en it is wat ik nedich. It bliuwt allinich om it opnij te skriuwen sadat alles wurket. Ik wachte op in frije jûn en begon de útfiering troch te tinken. Ik besleat om tabelkeppelingsregels (metadata) yn json te skriuwen. Ik hie gjin praktyske ûnderfining mei it wurkjen mei dit formaat en de hjoeddeistige taak waard sjoen as in kâns om dizze omisearring te korrigearjen.
Om mei json te wurkjen besleat ik de bibleteek te brûken fan Google. Dit is wêr't de ferrassingen begûnen. As it die bliken, waard dbeaver, as in echte applikaasje, skreaun op it Eclipse-platfoarm mei it OSGi-ramt. Foar betûfte ûntwikkelders makket dit ding it handich om ôfhinklikens te behearjen, mar foar my wie it mear as tsjustere magy, wêrfoar ik dúdlik net klear wie: lykas gewoanlik ymportearje ik de klassen dy't ik nedich bin fan 'e json-simple bibleteek yn' e koptekst fan de bewurke klasse, spesifisearje it yn 'e pom xml, wêrnei't it projekt kategoarysk wegeret om normaal te sammeljen en crasht mei flaters.
Uteinlik slagge it my om de boufouten te reparearjen: ik registrearre de bibleteek net yn pom.xml, mar yn it manifest.mf manifest, lykas fereaske troch OSGI, wylst it as ymportpakket oantsjutte. Net de moaiste oplossing, mar it wurket. Doe ferskynde de folgjende ferrassing. As jo ûntwikkelje yn Intellij Idea, kinne jo net gewoan gean en begjinne mei debuggen fan jo projekt basearre op it eclipse-platfoarm: in sûnder ûnderfining ûntwikkelder soe net minder moatte lije as in analist sûnder query-foltôging. De beverûntwikkelders sels kamen ta de rêding, oanjûn yn 'e wiki alle dûnsen mei in tamboeryn dy't dien wurde moatte. It meast ferfelende ding is dat sels nei al dizze squats it projekt net yn debug lansearre wurde woe mei de json-bibleteek ferbûn fia ymportpakket (nettsjinsteande it feit dat it noch mei sukses gearstald wie yn it fertikke produkt).
Tsjin dy tiid hie ik it ûngemak fan it brûken fan json foar myn taak al realisearre - de metadata soene ommers mei de hân bewurke wurde, en it xml-formaat is dêr better geskikt foar. It twadde argumint yn it foardiel fan xml wie de oanwêzigens fan alle nedige klassen yn 'e JDK, dy't it mooglik makke om te stopjen mei fjochtsjen mei in eksterne bibleteek. Mei in protte wille haw ik alle metadata oerbrocht fan json nei xml en begon te bewurkjen fan de autocomplete-logika.
Foarbyld fan Metadata
<?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>As gefolch I yn 'e SQLUtils- en SQLCompletionAnalyzer-klassen. It idee is dit: as it programma gjin passende suggestjes foar autofolje koe fine mei de basislogika, dan kontrolearret it op de oanwêzigens fan mooglike joins mei in eksterne xml-bestân. De triem sels bewarret pearen fan tabellen dy't de fjilden oanjaan wêrmei dizze tabellen keppele wurde moatte. Beperkingen op de technyske jildichheidsdatums fan records eff_dttm en exp_dttm en de logyske wiskjen flagge deleted_ind wurde standert ynsteld.
Doe't feroarings waarden makke oan 'e koade, kaam de fraach op - wa sil it bestân folje mei metadata? D'r binne in protte entiteiten yn 'e repository, it is djoer om alle ferbiningen sels te registrearjen. As gefolch haw ik besletten om dizze taak oan myn kollega-analisten te jaan. Ik pleatste de metadata triem yn svn, wêrfan in kassa wurdt makke nei de lokale map mei it programma. It prinsipe is dit: is in nije entiteit yn 'e repository ferskynd? Ien analist fiert mooglike joins yn it bestân, pleitet feroarings, de rest kontrolearje harsels en genietsje fan de wurkjende auto-foltôging: mienskip, accumulation fan kennis en al dat. Hat in workshop hâlden oer it brûken fan it programma foar kollega's, skreau in artikel yn Confluence - no hat it bedriuw noch ien handich ark.
Wurkje oan dizze funksje joech my it begryp dat d'r gjin need nedich is om bang te wêzen om te tinken mei iepen boarneprojekten - se hawwe yn 'e regel in dúdlike arsjitektuer, en sels basiskennis fan' e taal sil genôch wêze foar eksperiminten. En mei in bepaalde hoemannichte persistinsje sille jo sels haate routine operaasjes kinne kwytreitsje, en josels tiid besparje foar nije eksperiminten.
Boarne: www.habr.com