چگونه از انجام همان کار خودداری کنیم

آیا دوست دارید عملیات روتین را بارها و بارها تکرار کنید؟ پس من این کار را نمی کنم. اما هر بار که در کلاینت SQL هنگام کار با فضای ذخیره سازی Rostelecom، مجبور بودم همه اتصالات بین جداول را به صورت دستی ثبت کنم. و این در حالی است که در 90 درصد موارد فیلدها و شرایط پیوستن به جداول از پرس و جو به پرس و جو منطبق بود! به نظر می رسد که هر کلاینت SQL دارای توابع تکمیل خودکار است، اما برای ذخیره سازی ها همیشه کار نمی کند: آنها به ندرت شامل محدودیت منحصر به فرد و کلید خارجی برای بهبود عملکرد می شوند، و بدون این برنامه نمی داند چگونه موجودیت ها با هر یک مرتبط هستند. دیگر و آنچه می تواند برای شما ارائه دهد.

چگونه از انجام همان کار خودداری کنیم

با پشت سر گذاشتن انکار، عصبانیت، چانه زنی، افسردگی و نزدیک شدن به پذیرش، تصمیم گرفتم - چرا سعی نکنم خودم تکمیل خودکار را با بلک جک پیاده کنم و آن را به روش درست انجام دهم؟ من از کلاینت dbeaver استفاده می کنم که به زبان جاوا نوشته شده است، نسخه جامعه منبع باز دارد. یک طرح ساده به بلوغ رسیده است:

  1. کلاس هایی را در کد منبع پیدا کنید که مسئول تکمیل خودکار هستند
  2. آنها را به کار با ابرداده های خارجی هدایت کنید و اطلاعات مربوط به پیوست ها را از آنجا بیرون بکشید
  3. ؟
  4. سود (زیان)

من خیلی سریع اولین نکته را فهمیدم - در ردیاب اشکال درخواستی برای تنظیم تکمیل خودکار و در موارد مرتبط پیدا کردم مرتکب شدن کلاس SQLCompletionAnalyzer را کشف کرد. من به کد نگاه کردم و این همان چیزی است که نیاز دارم. تنها چیزی که باقی می ماند این است که آن را بازنویسی کنیم تا همه چیز کار کند. منتظر یک شب رایگان بودم و شروع به فکر کردن به اجرای آن کردم. تصمیم گرفتم قوانین پیوند جدول (فراداده) را در json بنویسم. من تجربه عملی کار با این قالب را نداشتم و وظیفه فعلی به عنوان فرصتی برای اصلاح این حذف تلقی می شد.

برای کار با json تصمیم گرفتم از کتابخانه استفاده کنم json-simple از گوگل از اینجا بود که شگفتی ها شروع شد. همانطور که مشخص شد، dbeaver، به عنوان یک برنامه واقعی، بر روی پلت فرم Eclipse با استفاده از چارچوب OSGi نوشته شده است. برای توسعه دهندگان باتجربه، این چیز مدیریت وابستگی ها را راحت می کند، اما برای من بیشتر شبیه جادوی تاریک بود، که به وضوح برای آن آماده نبودم: طبق معمول، کلاس های مورد نیاز خود را از کتابخانه json-simple در هدر وارد می کنم. کلاس ویرایش شده، آن را در pom.xml مشخص کنید، پس از آن پروژه به طور قاطعانه از مونتاژ عادی خودداری می کند و با خطا از کار می افتد.

در پایان، من موفق شدم خطاهای ساخت را برطرف کنم: من کتابخانه را نه در pom.xml، بلکه در manifest.mf مانیفست، همانطور که توسط OSGI نیاز است، ثبت کردم، در حالی که آن را به عنوان import-package مشخص کردم. زیباترین راه حل نیست، اما کار می کند. سپس شگفتی بعدی ظاهر شد. اگر در Intellij Idea توسعه می‌دهید، نمی‌توانید فقط بروید و اشکال‌زدایی پروژه خود را بر اساس پلتفرم eclipse شروع کنید: یک توسعه‌دهنده بی‌تجربه نباید کمتر از یک تحلیلگر بدون تکمیل پرس‌وجو متضرر شود. خود توسعه دهندگان Beaver به کمک آمدند و در ویکی نشان دادند که تمام رقص های با تنبور که باید انجام شود. آزاردهنده ترین چیز این است که حتی پس از تمام این اسکوات ها، پروژه نمی خواست در اشکال زدایی با کتابخانه 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

اضافه کردن نظر