Ձեզ դուր է գալիս կրկնել սովորական գործողությունները նորից ու նորից: Այնպես որ, ես չեմ: Բայց ամեն անգամ, երբ SQL հաճախորդում աշխատում էի Ռոստելեկոմի պահեստի հետ, ես ստիպված էի ձեռքով գրանցել բոլոր միացումները սեղանների միջև: Եվ դա չնայած այն հանգամանքին, որ 90% դեպքերում աղյուսակներին միանալու դաշտերը և պայմանները համընկնում էին հարցումից հարցում: Թվում է, թե ցանկացած SQL հաճախորդ ունի ավտոմատ լրացման գործառույթներ, բայց պահեստների համար այն միշտ չէ, որ աշխատում է. նրանք հազվադեպ են ներառում եզակի սահմանափակում և օտար բանալի՝ կատարողականությունը բարելավելու համար, և առանց դրա ծրագիրը չի իմանա, թե ինչպես են սուբյեկտները կապված յուրաքանչյուրի հետ: այլ և ինչ կարող է դա անել ձեզ համար:
Անցնելով ժխտման, զայրույթի, սակարկությունների, դեպրեսիայի և մոտենալով ընդունման միջով, ես որոշեցի. ինչու՞ չփորձեմ ինքս իրականացնել ինքնալրացում բլեքջեքով և անել դա ճիշտ ձևով: Ես օգտագործում եմ dbeaver հաճախորդը, գրված է java-ով, այն ունի բաց կոդով համայնքի տարբերակ։ Հասունացել է մի պարզ ծրագիր.
- Աղբյուրի կոդում գտեք դասեր, որոնք պատասխանատու են ավտոմատ լրացման համար
- Վերահղեք նրանց արտաքին մետատվյալների հետ աշխատելու և այնտեղից միացումների մասին տեղեկությունները հանեք
- ??
- Շահույթը
Ես բավականին արագ հասկացա առաջին կետը. սխալների հետագծում ես խնդրանք գտա՝ կարգավորելու ավտոմատ լրացումը և դրա հետ կապված հայտնաբերել է SQLCompletionAnalyzer դասը: Ես նայեցի կոդը և դա այն է, ինչ ինձ պետք է: Մնում է այն վերաշարադրել, որպեսզի ամեն ինչ աշխատի։ Ես սպասեցի անվճար երեկոյի և սկսեցի մտածել իրականացման մասին: Ես որոշեցի գրել աղյուսակի հղման կանոններ (մետատվյալներ) json-ում։ Այս ձևաչափով աշխատելու գործնական փորձ չունեի, և ներկայիս առաջադրանքը դիտվեց որպես այս բացթողումը շտկելու հնարավորություն։
json-ի հետ աշխատելու համար ես որոշեցի օգտագործել գրադարանը Google-ից: Այստեղից սկսվեցին անակնկալները։ Ինչպես պարզվեց, dbeaver-ը, որպես իսկական հավելված, գրվել է Eclipse հարթակի վրա՝ օգտագործելով OSGi շրջանակը։ Փորձառու ծրագրավորողների համար այս բանը հարմար է դարձնում կախվածությունները կառավարելը, բայց ինձ համար դա ավելի շատ նման էր մութ մոգության, որին ես ակնհայտորեն պատրաստ չէի. ինչպես միշտ, ես ներմուծում եմ ինձ անհրաժեշտ դասերը json-simple գրադարանից վերնագրում խմբագրված դասը, նշեք այն pom.xml-ում, որից հետո նախագիծը կտրականապես հրաժարվում է նորմալ հավաքվելուց և խափանում է սխալներով:
Ի վերջո, ես կարողացա շտկել build-ի սխալները. ես գրանցեցի գրադարանը ոչ թե pom.xml-ում, այլ manifest.mf manifest-ում, ինչպես պահանջում էր OSGI-ն՝ միաժամանակ նշելով որպես import-package։ Ամենագեղեցիկ լուծումը չէ, բայց այն աշխատում է։ Հետո հայտնվեց հաջորդ անակնկալը. Եթե դուք զարգանում եք Intellij Idea-ում, ապա չեք կարող պարզապես գնալ և սկսել կարգաբերել ձեր նախագիծը՝ հիմնվելով խավարման հարթակի վրա. անփորձ ծրագրավորողը պետք է տուժի ոչ պակաս, քան վերլուծաբանն առանց հարցումների ավարտի: Օգնության հասան իրենք՝ կավվեր մշակողները՝ վիքիում նշելով դափի հետ բոլոր պարերը, որոնք պետք է արվեն։ Ամենից զայրացնողն այն է, որ նույնիսկ այս բոլոր squats-ից հետո նախագիծը չցանկացավ գործարկել 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