Ви любите раз у раз повторювати рутинні операції? Ось і я нема. Але щоразу в SQL-клієнті під час роботи зі сховищем Ростелекома доводилося прописувати все джойни між таблицями ручками. І це при тому, що у 90% випадків поля та умови з'єднання таблиць збігалися від запиту до запиту! Здавалося б, будь-який SQL-клієнт має функції автозаповнення, але для сховищ воно не завжди працює: у них рідко заводяться unique constraint і foreign key з метою підвищення продуктивності, а без цього програмі не дізнатися, як між собою пов'язані сутності і що вона може тобі запропонувати.
Пройшовши через заперечення, гнів, торг, депресію та наближаючись до прийняття, я вирішив — а чому б самому не спробувати реалізувати автозаповнення з блэкджеком і як належить? Я користуюся клієнтом dbeaver, написаним на java, у нього є версія комьюніті з відкритим вихідним кодом. Дозрів нехитрий план:
- Знайти у вихідному коді класи, які відповідають за автозаповнення
- Переорієнтувати їх на роботу із зовнішніми метаданими та підтягувати звідти інформацію про джойни
- ???
- ПРИБУТОК
З першим пунктом досить швидко розібрався — знайшов у багтрекері запит на коригування автозаповнення та у зв'язаному
Для роботи з json вирішив використати бібліотеку
Виправити помилки збірки в результаті вийшло: прописав бібліотеку не в pom.xml, а в маніфесті manifest.mf, як це вимагає OSGI, при цьому вказавши її як import-package. Не найкрасивіше рішення, але працює. Тут виник наступний сюрприз. Якщо ти ведеш розробку в intellij idea, не можна просто так взяти і запустити дебаг свого проекту, заснованого на платформі eclipse: недосвідчений розробник повинен страждати не менше ніж аналітик без автодоповнення запитів. На допомогу прийшли самі розробники бобра, які вказали у wiki всі танці з бубном, які треба зробити. Найприкріше, що навіть після всіх цих присідань проект не хотів запускатися в дебазі з підключеною через import-package бібліотекою 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>
В результаті я
Коли виправлення в код було внесено, постало питання — хто наповнюватиме файл із метаданими? Сутностей у сховищі багато, самому зв'язки прописувати накладно. Зрештою вирішив повісити це завдання на своїх колег-аналітиків. Файл метаданих виклав у svn, звідки робиться чекають у локальну директорію з програмою. Принцип такий: у сховищі з'явилася нова суть? Один аналітик вносить можливі джойни у файл, коммітить зміни, інші роблять чекають до себе і насолоджуються працюючим автозаповненням: ком'юніті, накопичення знань і таке інше. Провів для колег воркшоп із використання проги, написав статтю в конфлюєнс — тепер у компанії одним зручним інструментом більше.
Робота над цією фічею дала мені розуміння, що не варто боятися колупати опенсорсні проекти — як правило, вони мають зрозумілу архітектуру, і навіть базових знань мови буде достатньо для експериментів. А за певної частки завзятості навіть вдасться позбутися ненависних рутинних операцій, заощадивши собі час на нові експерименти.
Джерело: habr.com