日常的な操作を何度も繰り返すのが好きですか? だから私はしません。 しかし、SQL クライアントで Rostelecom ストレージを操作するたびに、テーブル間のすべての結合を手動で登録する必要がありました。 これは、90% のケースで、テーブルを結合するためのフィールドと条件がリクエストごとに一致していたにもかかわらずです。 どの SQL クライアントにもオートコンプリート機能があるように見えますが、ストレージの場合は常に機能するとは限りません。パフォーマンスを向上させるために一意制約や外部キーが含まれることはほとんどありません。これがないと、プログラムはエンティティがそれぞれにどのように関連しているかを認識できません。その他、そしてそれがあなたに提供できること。
否定、怒り、駆け引き、憂鬱を経て、受け入れに近づいた私は、自分でブラックジャックの自動入力を正しい方法で実装してみてはどうだろうかと決心しました。 私は Java で書かれた dbeaver クライアントを使用しています。オープンソースのコミュニティ バージョンがあります。 シンプルなプランが完成しました:
- オートコンプリートを担当するソース コード内のクラスを見つける
- 外部メタデータを操作するようにそれらをリダイレクトし、そこから結合に関する情報を取得します。
- ?
- 利益
最初の点はすぐに理解できました。バグ トラッカーで自動入力を調整するリクエストと関連するリクエストを見つけました。
jsonを扱うためにライブラリを使用することにしました
最終的に、ビルド エラーを修正することができました。ライブラリを pom.xml ではなく、OSGI の要求に応じて、import-package として指定しながら、manifest.mf マニフェストに登録しました。 最も美しい解決策ではありませんが、機能します。 すると次の驚きが現れた。 Intellij Idea で開発している場合、Eclipse プラットフォームに基づいてプロジェクトのデバッグを開始することはできません。経験の浅い開発者は、クエリが完了しないとアナリストと同じように苦労するはずです。 ビーバーの開発者自身が救助に来て、タンバリンを使った必要なダンスをすべてwikiに示しました。 最も厄介なことは、これらすべてのスクワットの後でも、プロジェクトが import-package 経由で接続された json ライブラリを使用してデバッグで起動されることを望まなかったことです (完成品に正常にアセンブルされたにもかかわらず)。
その時点で、私は自分のタスクに json を使用することの不便さにすでに気づいていました。結局のところ、メタデータは手動で編集する必要があり、これには XML 形式の方が適していました。 xml を支持する XNUMX 番目の議論は、必要なクラスがすべて 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 で投稿し、そこからプログラムでローカル ディレクトリにチェックアウトが行われます。 原則は次のとおりです。新しいエンティティがリポジトリに出現したか? XNUMX 人のアナリストが結合の可能性をファイルに入力し、変更をコミットします。残りのアナリストは自分自身でチェックアウトし、機能するオートコンプリートを楽しみます。コミュニティ、知識の蓄積などです。 同僚向けにプログラムの使用に関するワークショップを実施し、Confluence で記事を書きました。現在、会社にはさらに便利なツールが XNUMX つあります。
この機能に取り組むことで、オープンソース プロジェクトをいじることを恐れる必要はないということがわかりました。一般に、オープンソース プロジェクトには明確なアーキテクチャがあり、実験には言語の基本的な知識さえあれば十分です。 また、ある程度の粘り強さがあれば、嫌いなルーチン操作をなくすこともでき、新しい実験に費やす時間を節約することもできます。
出所: habr.com