Бир эле нерсени кантип токтотсо болот

Күнүмдүк операцияларды кайра-кайра кайталаганды жактырасызбы? Ошондуктан мен андай эмес. Бирок SQL кардарында Ростелекомдун сактагычы менен иштеген сайын мен үстөлдөрдүн ортосундагы бардык кошулмаларды кол менен катташым керек болчу. Жана бул 90% учурларда талаалар жана таблицаларга кошулуу шарттары суроодон суроого дал келгенине карабастан! Кандайдыр бир SQL кардарында автоматтык түрдө бүтүрүү функциялары бар окшойт, бирок сактагычтар үчүн ал дайыма эле иштей бербейт: аткарууну жакшыртуу үчүн алар чанда гана уникалдуу чектөөнү жана тышкы ачкычты камтыйт, ансыз программа объектилердин ар бири менен кандай байланышы бар экенин билбейт. башка жана ал сиз үчүн эмне кыла алат.

Баш тартуу, ачуулануу, соодалашуу, депрессия жана кабыл алууга жакындап, мен чечтим - эмне үчүн автотолтурууну автотолтурууну блэкджек менен өзүм ишке ашырып, туура жол менен жасабайм? Мен javaда жазылган dbeaver кардарын колдоном, анын ачык булактуу коомчулук версиясы бар. Жөнөкөй план иштелип чыкты:

1. Булак кодунан автотолтурууга жооптуу класстарды табыңыз
2. Аларды тышкы метадайындар менен иштөөгө багыттаңыз жана ал жерден кошулуулар тууралуу маалыматты алыңыз
3. ??????
4. ПАЙДА

Мен биринчи ойду бат эле түшүндүм - каталарды көзөмөлдөөчүдөн автотолтурууну тууралоо өтүнүчүн таптым. жасоо SQLCompletionAnalyzer классын ачкан. Мен кодду карадым, бул мага керек. Баары иштей тургандай кылып кайра жазуу гана калды. Мен бекер кечти күтүп, ишке ашыруу аркылуу ойлоно баштадым. Мен json ичинде таблицага шилтеме эрежелерин (металыматтарды) жазууну чечтим. Бул формат менен иштөөдө практикалык тажрыйбам жок болчу жана азыркы тапшырма бул кемчиликти оңдоого мүмкүнчүлүк катары каралды.

json менен иштөө үчүн китепкананы колдонууну чечтим json-жөнөкөй Google'дан. Сюрприз мына жерден башталды. Маалым болгондой, dbeaver чыныгы тиркеме катары Eclipse платформасында OSGi алкагын колдонуу менен жазылган. Тажрыйбалуу иштеп чыгуучулар үчүн бул нерсе көз карандылыкты башкарууну ыңгайлуу кылат, бирок мен үчүн бул караңгы сыйкыр сыяктуу эле, мен ага даяр эмес элем: адаттагыдай эле, мен керектүү класстарды json-simple китепканасынын баш жагында импорттойм. түзөтүлгөн класс, аны pom.xml ичинде көрсөтүңүз, андан кийин долбоор нормалдуу түрдө чогултуудан кескин баш тартат жана каталар менен бузулат.

Акыр-аягы, мен куруу каталарын оңдоого жетиштим: китепкананы pom.xml эмес, OSGI талап кылган manifest.mf манифестинде, аны импорттук пакет катары көрсөтүү менен каттадым. Эң сонун чечим эмес, бирок ал иштейт. Анан кийинки сюрприз пайда болду. Эгерде сиз Intellij Idea-да иштеп жатсаңыз, анда сиз жөн эле барып, тутулуу платформасынын негизинде өзүңүздүн проектиңизди оңдоону баштай албайсыз: тажрыйбасыз иштеп чыгуучу сурамдарды аягына чыгарбай туруп, аналитиктен кем эмес кыйналышы керек. Кундызды иштеп чыгуучулар өздөрү жардамга келишти, алар викиде дап менен жасалышы керек болгон бардык бийлерди көрсөтүштү. Эң тажатма нерсе, бул скваттардан кийин дагы, долбоор импорт-пакет аркылуу туташтырылган json китепканасы менен мүчүлүштүктөрдү тапкысы келген жок (ал дагы эле даяр продукцияга ийгиликтүү чогултулганына карабастан).

Ошол убакта мен өзүмдүн тапшырмам үчүн json колдонуунун ыңгайсыздыгын түшүнгөн элем - акыры, метаберилиштер кол менен редакцияланышы керек болчу жана бул үчүн xml форматы жакшыраак ылайыктуу. xml пайдасына экинчи аргумент JDKда бардык керектүү класстардын болушу болду, бул тышкы китепкана менен күрөштү токтотууга мүмкүндүк берди. Чоң ырахат менен мен бардык метаберилиштерди jsonдан xmlге өткөрүп, автотолтуруунун логикасын түзөтө баштадым.

Метадайындардын мисалы

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

Натыйжада И өзгөртүүлөрдү киргизди SQLUtils жана SQLCompletionAnalyzer класстарына. Идея мындай: эгерде программа негизги логиканы колдонуу менен ылайыктуу автотолтуруучу сунуштарды таба албаса, анда тышкы xml файлын колдонуу менен мүмкүн болгон кошулмалардын бар-жоктугун текшерет. Файлдын өзү бул таблицаларды байланыштыруу керек болгон талааларды көрсөткөн жуп таблицаларды сактайт. eff_dttm жана exp_dttm жазууларынын техникалык жарактуу даталарына чектөөлөр жана deleted_ind логикалык өчүрүү желеги демейки боюнча коюлган.

Кодго өзгөртүүлөр киргизилгенде, суроо пайда болду - файлды метадайындар менен ким толтурат? Репозиторийде көптөгөн объекттер бар, бардык байланыштарды өзүңүз каттатуу кымбатка турат. Жыйынтыгында мен бул милдетти аналитик кесиптештериме тапшырууну чечтим. Мен метадайындар файлын svn ичинде жайгаштырдым, ал жерден программа менен жергиликтүү каталогго текшерүү жүргүзүлөт. Принцип мындай: репозиторийде жаңы объект пайда болдубу? Бир аналитик файлга мүмкүн болгон кошулмаларды киргизип, өзгөртүүлөрдү киргизет, калгандары өздөрүн текшерип, автоматтык түрдө иштөөдөн ырахат алышат: коомчулук, билимдин топтолушу жана башка. Кесиптештер үчүн программаны колдонуу боюнча семинар өткөрдү, Confluence журналына макала жазды - азыр компанияда дагы бир ыңгайлуу курал бар.

Бул функциянын үстүндө иштөө мага ачык булак долбоорлору менен алектенүүдөн коркуунун кереги жок экенин түшүндү - эреже катары, алардын так архитектурасы бар, ал тургай, эксперименттер үчүн тил боюнча негизги билим жетиштүү болот. Жана белгилүү бир өжөрлүк менен сиз жаңы эксперименттерге убакытты үнөмдөп, жек көрүүчү күнүмдүк операциялардан да арыла аласыз.

Source: www.habr.com