ဒီလိုလုပ်နေတာကို ဘယ်လိုရပ်မလဲ။

ပုံမှန်လုပ်ငန်းဆောင်တာများကို ထပ်ခါထပ်ခါ ပြန်လုပ်လိုပါသလား။ ဒါကြောင့် ငါမလုပ်ဘူး။ သို့သော် Rostelecom သိုလှောင်မှုနှင့်အတူအလုပ်လုပ်သောအခါ SQL client တွင်အချိန်တိုင်း၊ ကျွန်ုပ်သည် tables များကြားတွင် join အားလုံးကိုကိုယ်တိုင်စာရင်းသွင်းရန်လိုအပ်သည်။ ဤအရာသည် အမှုအခင်းများ၏ 90% တွင် ဇယားများပါဝင်ခြင်းအတွက် နယ်ပယ်များနှင့် အခြေအနေများသည် တောင်းဆိုမှုမှ တောင်းဆိုချက်မှ တိုက်ဆိုင်နေသော်လည်း ၎င်းသည်! မည်သည့် SQL ကလိုင်းယင့်တွင်မဆို အလိုအလျောက် ဖြည့်သွင်းသည့် လုပ်ဆောင်ချက်များ ရှိပုံရသော်လည်း သိုလှောင်မှုများအတွက် ၎င်းသည် အမြဲတမ်း အလုပ်မဖြစ်ပါ- ၎င်းတို့တွင် စွမ်းဆောင်ရည် မြှင့်တင်ရန်အတွက် ထူးခြားသော ကန့်သတ်ချက်နှင့် နိုင်ငံခြားကီးများ ပါဝင်ခဲပြီး၊ ၎င်းမပါဘဲ ပရိုဂရမ်သည် တစ်ခုချင်းစီနှင့် မည်သို့ဆက်စပ်နေသည်ကို မသိနိုင်ပါ။ အခြား နှင့် ၎င်းသည် သင့်အတွက် မည်ကဲ့သို့ လုပ်ဆောင်နိုင်သနည်း။

ငြင်းဆိုခြင်း၊ ဒေါသဖြစ်ခြင်း၊ အလျှော့အတင်းလုပ်ခြင်း၊ စိတ်ဓာတ်ကျခြင်းနှင့် လက်ခံခြင်းတို့ကို ချဉ်းကပ်ခြင်းတို့ကို ဖြတ်သန်းပြီးနောက်၊ ကျွန်ုပ် ဆုံးဖြတ်ခဲ့သည်- ကျွန်ုပ်သည် ဘလက်ဂျက်ဖြင့် အလိုအလျောက်ဖြည့်သွင်းရန် မကြိုးစားဘဲ ၎င်းကို နည်းလမ်းမှန်အတိုင်း လုပ်ဆောင်ရန် အဘယ်ကြောင့် မကြိုးစားသနည်း။ ကျွန်ုပ်သည် java တွင်ရေးသားထားသော dbeaver client ကိုအသုံးပြုသည်၊ ၎င်းတွင် open source အသိုင်းအဝိုင်းဗားရှင်းတစ်ခုရှိသည်။ ရိုးရှင်းသောအစီအစဥ်တစ်ခု ပြည့်စုံလာပါပြီ-

1. အလိုအလျောက်ဖြည့်ပေးမှုအတွက် တာဝန်ရှိသော အရင်းအမြစ်ကုဒ်ရှိ အတန်းများကို ရှာပါ။
2. ၎င်းတို့ကို ပြင်ပ မက်တာဒေတာဖြင့် လုပ်ဆောင်ရန် ၎င်းတို့ကို ပြန်ညွှန်းပြီး ထိုနေရာမှ ချိတ်ဆက်မှုများအကြောင်း အချက်အလက်ကို ဆွဲထုတ်ပါ။
3. ??????
4. အမြတ်အစွန်း

ပထမအချက်ကို အတော်လေး မြန်မြန်ဆန်ဆန် တွေးကြည့်မိတယ် - အော်တိုဖြည့်ခြင်းနှင့် ဆက်စပ်မှုအား ချိန်ညှိရန် bug tracker တွင် တောင်းဆိုချက်တစ်ခုကို တွေ့ရှိခဲ့သည်။ ကျူးလွန်သည်။ SQLCompletionAnalyzer အတန်းကို ရှာဖွေတွေ့ရှိခဲ့သည်။ ကုဒ်ကိုကြည့်လိုက်တော့ အဲဒါက ငါလိုတယ်။ ကျန်တာအားလုံး အဆင်ပြေအောင် ပြန်ရေးဖို့ပဲကျန်တော့တယ်။ အလကားရတဲ့ညနေခင်းကို စောင့်ဆိုင်းပြီး အကောင်အထည်ဖော်ဖို့ စဉ်းစားခဲ့တယ်။ json တွင် table link rules (metadata) ကိုရေးရန် ဆုံးဖြတ်ခဲ့သည်။ ကျွန်ုပ်တွင် ဤပုံစံဖြင့် လုပ်ဆောင်သည့် လက်တွေ့ အတွေ့အကြုံမရှိသဖြင့် လက်ရှိတာဝန်သည် ဤပျက်ကွက်မှုကို ပြုပြင်ရန် အခွင့်အရေးတစ်ခုအဖြစ် ရှုမြင်ပါသည်။

json နဲ့အလုပ်လုပ်ဖို့အတွက် library ကိုသုံးဖို့ဆုံးဖြတ်လိုက်တယ်။ json-ရိုးရှင်းသော Google မှ ဤနေရာတွင် အံ့သြစရာများ စတင်ခဲ့သည်။ ထွက်ပေါ်လာသည့်အတိုင်း dbeaver သည် စစ်မှန်သော application တစ်ခုအနေဖြင့် OSGi framework ကိုအသုံးပြု၍ Eclipse platform ပေါ်တွင် ရေးသားခဲ့သည်။ အတွေ့အကြုံရင့် developer များအတွက်၊ ဤအရာသည် မှီခိုအားထားမှုကို စီမံခန့်ခွဲရန် အဆင်ပြေစေသည်၊ သို့သော် ကျွန်ုပ်အတွက်မူ အဆင်သင့်မဖြစ်သေးသည့်အတွက် မှောင်မိုက်သောမှော်ပညာနှင့် ပိုတူပါသည်- ထုံးစံအတိုင်း၊ ခေါင်းစီးရှိ json-ရိုးရှင်းစာကြည့်တိုက်မှ လိုအပ်သောအတန်းများကို တင်သွင်းပါသည်။ တည်းဖြတ်ထားသော အတန်းကို pom. xml တွင် သတ်မှတ်ပါ၊ ထို့နောက် ပရောဂျက်သည် ပုံမှန်အတိုင်း စုစည်းရန် လုံးဝငြင်းဆန်ပြီး အမှားအယွင်းများနှင့် ပျက်သွားသည်။

အဆုံးတွင်၊ ကျွန်ုပ်သည် တည်ဆောက်မှုအမှားများကို ပြင်ဆင်နိုင်ပါသည်- ကျွန်ုပ်သည် စာကြည့်တိုက်ကို pom.xml တွင်မဖော်ပြထားဘဲ OSGI ၏ လိုအပ်ချက်အရ မန်နီးဖက်စ်.mf မန်နီးဖက်စ်တွင်၊ ၎င်းကို သွင်းကုန်-ပက်ကေ့ချ်အဖြစ် သတ်မှတ်နေစဉ်။ အလှပဆုံးဖြေရှင်းချက်မဟုတ်သော်လည်း၊ ၎င်းသည်အလုပ်လုပ်သည်။ နောက်တော့ အံ့အားသင့်စရာ ပေါ်လာတယ်။ အကယ်၍ သင်သည် Intellij Idea တွင် တီထွင်နေပါက၊ သင်သည် နေကြတ်ခြင်းပလပ်ဖောင်းကို အခြေခံ၍ သင့်ပရောဂျက်ကို အမှားရှာစတင်၍ မရနိုင်ပါ- အတွေ့အကြုံမရှိသော ဆော့ဖ်ဝဲရေးသားသူသည် စုံစမ်းမေးမြန်းမှု မပြီးပြတ်ဘဲ ခွဲခြမ်းစိတ်ဖြာသူထက် မနည်းတော့ပါ။ beaver developer များကိုယ်တိုင်က ကယ်ဆယ်ရန် ရောက်လာပြီး လုပ်ဆောင်ရန် လိုအပ်သည့် ပတ်သာနှင့် အကများအားလုံးကို wiki တွင် ညွှန်ပြသည်။ စိတ်အနှောက်အယှက်ဖြစ်စရာအကောင်းဆုံးအချက်မှာ squats အားလုံးပြီးနောက်တွင်ပင်၊ ပရောဂျက်သည် import-package မှတစ်ဆင့်ချိတ်ဆက်ထားသော json library နှင့် debug တွင်မဖွင့်လိုဘဲ (၎င်းကို ကုန်ချောတွင်အောင်မြင်စွာစုစည်းထားဆဲဖြစ်သည်ဟူသောအချက်ပင်)။

ထိုအချိန်တွင်၊ ကျွန်ုပ်၏လုပ်ငန်းတာဝန်အတွက် json ကိုအသုံးပြုရန် အဆင်မပြေကြောင်း နားလည်ထားပြီးဖြစ်သည် - နောက်ဆုံးတွင်၊ မက်တာဒေတာကို ကိုယ်တိုင်တည်းဖြတ်ရမည်ဟု ယူဆရပြီး xml ဖော်မတ်သည် ၎င်းအတွက် ပိုသင့်လျော်ပါသည်။ xml ၏မျက်နှာသာပေးသည့်ဒုတိယအငြင်းအခုံမှာ JDK တွင်လိုအပ်သောအတန်းများအားလုံးရှိနေခြင်းဖြစ်ပြီး၊ ပြင်ပစာကြည့်တိုက်နှင့်တိုက်ခိုက်ခြင်းကိုရပ်တန့်နိုင်စေခဲ့သည်။ ပျော်ရွှင်စွာဖြင့်၊ json မှ xml သို့ metadata အားလုံးကို လွှဲပြောင်းပြီး autocomplete logic ကို စတင်ပြင်ဆင်ခဲ့ပါသည်။

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>

ရလဒ်အနေနဲ့ ငါ အပြောင်းအလဲများ ပြုလုပ်ခဲ့သည်။ SQLUtils နှင့် SQLCompletionAnalyzer အတန်းများထဲသို့။ အယူအဆမှာ ဤသို့ဖြစ်သည်- အကယ်၍ ပရိုဂရမ်သည် အခြေခံယုတ္တိဗေဒကို အသုံးပြု၍ သင့်လျော်သော အလိုအလျောက်ဖြည့်စွက်အကြံပြုချက်များကို ရှာမတွေ့ပါက၊ ထို့နောက် ပြင်ပ xml ဖိုင်ကို အသုံးပြု၍ ချိတ်ဆက်မှု ဖြစ်နိုင်ချေရှိမရှိကို စစ်ဆေးသည်။ ဖိုင်ကိုယ်တိုင်က ဤဇယားများကို ချိတ်ဆက်ရန် လိုအပ်သည့် အကွက်များကို ညွှန်ပြသည့် ဇယားအတွဲများကို သိမ်းဆည်းထားသည်။ eff_dttm နှင့် exp_dttm မှတ်တမ်းများ၏ နည်းပညာဆိုင်ရာတရားဝင်သည့်ရက်စွဲများအပေါ် ကန့်သတ်ချက်များ နှင့် ယုတ္တိတန်သောဖျက်မှုအလံ deleted_ind ကို ပုံသေသတ်မှတ်ထားသည်။

ကုဒ်ကို အပြောင်းအလဲလုပ်သောအခါတွင် မေးခွန်းပေါ်လာသည် - ဖိုင်ကို မက်တာဒေတာဖြင့် မည်သူဖြည့်ပေးမည်နည်း။ repository တွင် entities များစွာရှိသည်၊ ချိတ်ဆက်မှုအားလုံးကို ကိုယ်တိုင်မှတ်ပုံတင်ရန် စျေးကြီးသည်။ ထို့ကြောင့် ကျွန်ုပ်သည် ဤတာဝန်ကို ကျွန်ုပ်၏လုပ်ဖော်ကိုင်ဖက် အကဲခတ်များထံ ပေးအပ်ရန် ဆုံးဖြတ်ခဲ့သည်။ ကျွန်ုပ်သည် ပရိုဂရမ်ဖြင့် ငွေပေးချေမှုပြုလုပ်သည့်နေရာမှ မက်တာဒေတာဖိုင်ကို svn တွင် တင်ခဲ့သည်။ နိယာမသည် ဤအရာဖြစ်သည်- repository တွင် entity အသစ်တစ်ခုပေါ်လာပါသလား။ အကဲခတ်သူတစ်ဦးသည် ဖိုင်ထဲသို့ ဖြစ်နိုင်ချေရှိသော ချိတ်ဆက်မှုများကို ထည့်သွင်းကာ အပြောင်းအလဲများကို ကျူးလွန်သည်၊ ကျန်သူများသည် ၎င်းတို့ကို စစ်ဆေးပြီး အလုပ်လုပ်သော အလိုအလျောက် ပြီးဆုံးခြင်း- အသိုင်းအဝိုင်း၊ အသိပညာ စုဆောင်းခြင်းနှင့် အရာအားလုံးကို ခံစားလိုက်ပါ။ လုပ်ဖော်ကိုင်ဖက်များအတွက် ပရိုဂရမ်ကို အသုံးပြုခြင်းဆိုင်ရာ အလုပ်ရုံဆွေးနွေးပွဲတစ်ခု ပြုလုပ်ခဲ့ပြီး မြစ်ဆုံတွင် ဆောင်းပါးတစ်ပုဒ် ရေးသားခဲ့သည် - ယခုအခါ ကုမ္ပဏီတွင် ပိုမိုအဆင်ပြေသည့် ကိရိယာတစ်ခု ရှိလာပြီဖြစ်သည်။

ဤအင်္ဂါရပ်ကိုလုပ်ဆောင်ခြင်းဖြင့် open source ပရောဂျက်များနှင့် တွဲလုပ်ရန် ကြောက်ရွံ့နေရန် မလိုအပ်ကြောင်း နားလည်စေသည် - စည်းကမ်းအနေဖြင့် ၎င်းတို့တွင် ရှင်းလင်းသောဗိသုကာပညာရှိပြီး ဘာသာစကား၏အခြေခံအသိပညာသည် စမ်းသပ်မှုများအတွက် လုံလောက်မည်ဖြစ်သည်။ အတိုင်းအတာတစ်ခုအထိ စွဲမြဲစွာလုပ်ဆောင်ခြင်းဖြင့် သင်သည် အမုန်းပွားစေသော ပုံမှန်လုပ်ငန်းဆောင်တာများကို ဖယ်ရှားပစ်နိုင်ပြီး စမ်းသပ်မှုအသစ်များအတွက် သင့်ကိုယ်သင် အချိန်ကုန်သက်သာစေမည်ဖြစ်သည်။

source: www.habr.com