🥇एकच गोष्ट करणे कसे थांबवायचे

तुम्हाला नियमित ऑपरेशन्स पुन्हा पुन्हा करायला आवडते का? म्हणून मी नाही. परंतु प्रत्येक वेळी एसक्यूएल क्लायंटमध्ये रोस्टेलेकॉम स्टोरेजसह काम करताना, मला टेबलमधील सर्व जोडणी मॅन्युअली नोंदणी करावी लागली. आणि हे असूनही 90% प्रकरणांमध्ये टेबलमध्ये सामील होण्यासाठी फील्ड आणि अटी विनंती ते विनंतीशी जुळतात! असे दिसते की कोणत्याही एसक्यूएल क्लायंटमध्ये स्वयं-पूर्ण कार्ये असतात, परंतु स्टोरेजसाठी ते नेहमीच कार्य करत नाही: कार्यप्रदर्शन सुधारण्यासाठी ते क्वचितच अद्वितीय मर्यादा आणि परदेशी की समाविष्ट करतात आणि त्याशिवाय प्रोग्रामला प्रत्येक घटकाशी कसे संबंधित आहेत हे कळणार नाही. इतर आणि ते आपल्यासाठी काय देऊ शकते.

नकार, राग, सौदेबाजी, नैराश्य आणि स्वीकृती जवळ आल्यावर, मी ठरवले - स्वत: ब्लॅकजॅकसह ऑटोफिल लागू करण्याचा प्रयत्न का करू नये आणि ते योग्य मार्गाने करू नये? मी जावा मध्ये लिहिलेले dbeaver क्लायंट वापरतो, त्याची मुक्त स्रोत समुदाय आवृत्ती आहे. एक साधी योजना परिपक्व झाली आहे:

स्त्रोत कोडमधील वर्ग शोधा जे स्वयंपूर्णतेसाठी जबाबदार आहेत
बाह्य मेटाडेटासह कार्य करण्यासाठी त्यांना पुनर्निर्देशित करा आणि तेथून सामील होण्याबद्दल माहिती काढा
??????
लाभ

मला पहिला मुद्दा अगदी पटकन समजला - मला बग ट्रॅकरमध्ये ऑटोफिल समायोजित करण्याची विनंती आढळली आणि संबंधित वचनबद्ध SQLCompletionAnalyser वर्ग शोधला. मी कोड पाहिला आणि मला तेच हवे आहे. बाकी ते पुन्हा लिहायचे आहे जेणेकरून सर्वकाही कार्य करेल. मी मोकळ्या संध्याकाळची वाट पाहिली आणि अंमलबजावणीद्वारे विचार करू लागलो. मी json मध्ये टेबल लिंक नियम (मेटाडेटा) लिहिण्याचा निर्णय घेतला. मला या फॉर्मेटमध्ये काम करण्याचा कोणताही व्यावहारिक अनुभव नव्हता आणि सध्याचे कार्य ही चूक सुधारण्याची संधी म्हणून पाहिले जात होते.

json सोबत काम करण्यासाठी मी लायब्ररी वापरण्याचा निर्णय घेतला json-साधा Google कडून. इथूनच आश्चर्याची सुरुवात झाली. असे झाले की, dbeaver, खरा अनुप्रयोग म्हणून, OSGi फ्रेमवर्क वापरून Eclipse प्लॅटफॉर्मवर लिहिले गेले. अनुभवी विकसकांसाठी, ही गोष्ट अवलंबित्व व्यवस्थापित करणे सोयीस्कर बनवते, परंतु माझ्यासाठी ते अधिक गडद जादूसारखे होते, ज्यासाठी मी स्पष्टपणे तयार नव्हतो: नेहमीप्रमाणे, मी जेसन-सिंपल लायब्ररीच्या शीर्षलेखातील मला आवश्यक असलेले वर्ग आयात करतो. संपादित वर्ग, तो pom. xml मध्ये निर्दिष्ट करा, त्यानंतर प्रकल्प स्पष्टपणे सामान्यपणे एकत्र येण्यास नकार देतो आणि त्रुटींसह क्रॅश होतो.

शेवटी, मी बिल्ड त्रुटींचे निराकरण करण्यात व्यवस्थापित केले: मी लायब्ररी pom.xml मध्ये नाही तर manifest.mf मॅनिफेस्टमध्ये नोंदणीकृत केली आहे, OSGI च्या आवश्यकतेनुसार, आयात-पॅकेज म्हणून निर्दिष्ट करताना. सर्वात सुंदर उपाय नाही, परंतु ते कार्य करते. मग पुढचे आश्चर्य दिसले. जर तुम्ही 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 आणि SQLCompletionAnalyser वर्गांमध्ये. कल्पना अशी आहे: जर प्रोग्राम मूलभूत तर्क वापरून योग्य स्वयंपूर्ण सूचना शोधण्यात अक्षम असेल, तर तो बाह्य xml फाइल वापरून संभाव्य जोडणीची उपस्थिती तपासतो. फाइल स्वतःच सारण्यांच्या जोड्या संग्रहित करते ज्या फील्डद्वारे या सारण्यांना लिंक करणे आवश्यक आहे. eff_dttm आणि exp_dttm रेकॉर्डच्या तांत्रिक वैधता तारखांवर निर्बंध आणि तार्किक हटविण्याचा ध्वज deleted_ind डीफॉल्टनुसार सेट केला जातो.

कोडमध्ये बदल केल्यावर, प्रश्न उद्भवला - मेटाडेटासह फाइल कोण भरेल? रेपॉजिटरीमध्ये बर्याच संस्था आहेत, सर्व कनेक्शन स्वतः नोंदणी करणे महाग आहे. परिणामी, मी हे काम माझ्या सहकारी विश्लेषकांना सोपवण्याचा निर्णय घेतला. मी मेटाडेटा फाइल svn मध्ये पोस्ट केली, जिथून प्रोग्रामसह स्थानिक निर्देशिकेत चेकआउट केले जाते. तत्त्व हे आहे: भांडारात नवीन अस्तित्व दिसले आहे का? एक विश्लेषक फाइलमध्ये संभाव्य सामील होऊन प्रवेश करतो, बदल करतो, बाकीचे स्वतःकडे तपासतात आणि कार्यरत स्वयं-पूर्णतेचा आनंद घेतात: समुदाय, ज्ञानाचा संचय आणि हे सर्व. सहकाऱ्यांसाठी प्रोग्राम वापरण्यावर एक कार्यशाळा आयोजित केली, कॉन्फ्लुएंसमध्ये एक लेख लिहिला - आता कंपनीकडे आणखी एक सोयीस्कर साधन आहे.

या वैशिष्ट्यावर काम केल्याने मला हे समजले की ओपन सोर्स प्रकल्पांमध्ये छेडछाड करण्यास घाबरण्याची गरज नाही - नियमानुसार, त्यांच्याकडे एक स्पष्ट आर्किटेक्चर आहे आणि भाषेचे मूलभूत ज्ञान देखील प्रयोगांसाठी पुरेसे असेल. आणि ठराविक चिकाटीने, तुम्ही तिरस्कारयुक्त नियमित ऑपरेशन्सपासून मुक्त होण्यास सक्षम असाल, नवीन प्रयोगांसाठी स्वतःचा वेळ वाचवू शकाल.

स्त्रोत: www.habr.com

तीच गोष्ट करणे कसे थांबवायचे

एक टिप्पणी जोडा Отменить ответ