ایک ہی کام کرنے سے کیسے روکا جائے۔

کیا آپ معمول کی کارروائیوں کو بار بار دہرانا پسند کرتے ہیں؟ تو میں نہیں کرتا۔ لیکن جب بھی ایس کیو ایل کلائنٹ میں Rostelecom سٹوریج کے ساتھ کام کرتے تھے، مجھے میزوں کے درمیان تمام جوائنز کو دستی طور پر رجسٹر کرنا پڑتا تھا۔ اور یہ اس حقیقت کے باوجود کہ 90% معاملات میں ٹیبلز میں شامل ہونے کے لیے فیلڈز اور شرائط ایک سوال سے دوسرے سوال کے ساتھ ملتی ہیں! ایسا لگتا ہے کہ کسی بھی ایس کیو ایل کلائنٹ کے پاس خودکار تکمیل کے افعال ہوتے ہیں، لیکن سٹوریجز کے لیے یہ ہمیشہ کام نہیں کرتا: کارکردگی کو بہتر بنانے کے لیے ان میں شاذ و نادر ہی انوکھی رکاوٹ اور غیر ملکی کلید شامل ہوتی ہے، اور اس کے بغیر پروگرام کو یہ معلوم نہیں ہو گا کہ ہر ایک سے کس طرح کا تعلق ہے۔ دوسرے اور یہ آپ کے لیے کیا کر سکتا ہے۔

انکار، غصہ، سودے بازی، افسردگی اور قبولیت کے قریب پہنچنے کے بعد، میں نے فیصلہ کیا - کیوں نہ خود بلیک جیک کے ساتھ آٹوفل کو لاگو کرنے کی کوشش کریں اور اسے صحیح طریقے سے کریں؟ میں جاوا میں لکھا ہوا ڈیبیور کلائنٹ استعمال کرتا ہوں، اس کا اوپن سورس کمیونٹی ورژن ہے۔ ایک سادہ منصوبہ پختہ ہو گیا ہے:

1. سورس کوڈ میں کلاسز تلاش کریں جو خودکار تکمیل کے لیے ذمہ دار ہیں۔
2. انہیں بیرونی میٹا ڈیٹا کے ساتھ کام کرنے کے لیے ری ڈائریکٹ کریں اور وہاں سے شمولیت کے بارے میں معلومات کھینچیں۔
3. ؟؟
4. منافع

میں نے پہلا نکتہ بہت تیزی سے سمجھ لیا - مجھے بگ ٹریکر میں آٹو فل کو ایڈجسٹ کرنے کی درخواست ملی اور اس سے متعلقہ عزم SQLCompletionAnalyzer کلاس دریافت کی۔ میں نے کوڈ کو دیکھا اور یہ وہی ہے جس کی مجھے ضرورت ہے۔ جو کچھ باقی ہے اسے دوبارہ لکھنا ہے تاکہ سب کچھ کام کر سکے۔ میں نے ایک آزاد شام کا انتظار کیا اور نفاذ کے ذریعے سوچنا شروع کیا۔ میں نے json میں ٹیبل لنک رولز (میٹا ڈیٹا) لکھنے کا فیصلہ کیا۔ مجھے اس فارمیٹ کے ساتھ کام کرنے کا کوئی عملی تجربہ نہیں تھا اور موجودہ کام کو اس کوتاہی کو درست کرنے کے ایک موقع کے طور پر دیکھا گیا۔

json کے ساتھ کام کرنے کے لیے میں نے لائبریری کو استعمال کرنے کا فیصلہ کیا۔ json-سادہ گوگل سے یہیں سے حیرتوں کا آغاز ہوا۔ جیسا کہ یہ نکلا، dbeaver، ایک حقیقی ایپلی کیشن کے طور پر، OSGi فریم ورک کا استعمال کرتے ہوئے Eclipse پلیٹ فارم پر لکھا گیا تھا۔ تجربہ کار ڈویلپرز کے لیے، یہ چیز انحصار کا انتظام کرنا آسان بناتی ہے، لیکن میرے لیے یہ زیادہ گہرے جادو کی طرح تھا، جس کے لیے میں واضح طور پر تیار نہیں تھا: ہمیشہ کی طرح، میں ان کلاسوں کو درآمد کرتا ہوں جن کی مجھے json-simple لائبریری کے ہیڈر میں ضرورت ہوتی ہے۔ ترمیم شدہ کلاس، اسے 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 اور SQLCompletionAnalyzer کلاسز میں۔ خیال یہ ہے: اگر پروگرام بنیادی منطق کا استعمال کرتے ہوئے مناسب خود کار طریقے سے مکمل تجاویز تلاش کرنے سے قاصر تھا، تو یہ ایک بیرونی xML فائل کا استعمال کرتے ہوئے ممکنہ شمولیت کی موجودگی کی جانچ کرتا ہے۔ فائل خود ٹیبلز کے جوڑے اسٹور کرتی ہے جو ان فیلڈز کی نشاندہی کرتی ہے جن کے ذریعے ان ٹیبلز کو لنک کرنے کی ضرورت ہوتی ہے۔ ریکارڈز eff_dttm اور exp_dttm کی تکنیکی درستگی کی تاریخوں پر پابندیاں اور منطقی حذف کرنے والے جھنڈے deleted_ind پہلے سے طے شدہ ہیں۔

جب کوڈ میں تبدیلیاں کی گئیں تو سوال پیدا ہوا کہ فائل کو میٹا ڈیٹا سے کون بھرے گا؟ ریپوزٹری میں بہت سے ادارے موجود ہیں، تمام کنکشنز کو خود رجسٹر کرنا مہنگا ہے۔ نتیجے کے طور پر، میں نے یہ کام اپنے ساتھی تجزیہ کاروں کو سونپنے کا فیصلہ کیا۔ میں نے میٹا ڈیٹا فائل کو svn میں پوسٹ کیا، جہاں سے پروگرام کے ساتھ مقامی ڈائریکٹری میں چیک آؤٹ کیا جاتا ہے۔ اصول یہ ہے: کیا ذخیرہ میں کوئی نئی ہستی نمودار ہوئی ہے؟ ایک تجزیہ کار فائل میں ممکنہ شمولیت میں داخل ہوتا ہے، تبدیلیوں کا ارتکاب کرتا ہے، باقی خود کو چیک آؤٹ کرتے ہیں اور کام کرنے والی خودکار تکمیل سے لطف اندوز ہوتے ہیں: کمیونٹی، علم کا ذخیرہ اور یہ سب کچھ۔ ساتھیوں کے لیے پروگرام کے استعمال پر ایک ورکشاپ کا انعقاد کیا، Confluence میں ایک مضمون لکھا - اب کمپنی کے پاس ایک اور آسان ٹول ہے۔

اس خصوصیت پر کام کرنے سے مجھے یہ سمجھ آئی کہ اوپن سورس پروجیکٹس کے ساتھ ٹنکر کرنے سے گھبرانے کی ضرورت نہیں ہے - ایک اصول کے طور پر، ان کا ایک واضح فن تعمیر ہے، اور زبان کا بنیادی علم بھی تجربات کے لیے کافی ہوگا۔ اور ایک خاص مقدار میں استقامت کے ساتھ، آپ یہاں تک کہ نفرت انگیز روٹین آپریشنز سے چھٹکارا حاصل کرنے کے قابل ہو جائیں گے، اپنے آپ کو نئے تجربات کے لیے وقت بچائیں گے۔

ماخذ: www.habr.com