🥇同じことをやめる方法

日常的な操作を何度も繰り返すのが好きですか? だから私はしません。しかし、SQL クライアントで Rostelecom ストレージを操作するたびに、テーブル間のすべての結合を手動で登録する必要がありました。これは、90% のケースで、テーブルを結合するためのフィールドと条件がリクエストごとに一致していたにもかかわらずです。どの SQL クライアントにもオートコンプリート機能があるように見えますが、ストレージの場合は常に機能するとは限りません。パフォーマンスを向上させるために一意制約や外部キーが含まれることはほとんどありません。これがないと、プログラムはエンティティがそれぞれにどのように関連しているかを認識できません。その他、そしてそれがあなたに提供できること。

否定、怒り、駆け引き、憂鬱を経て、受け入れに近づいた私は、自分でブラックジャックの自動入力を正しい方法で実装してみてはどうだろうかと決心しました。私は Java で書かれた dbeaver クライアントを使用しています。オープンソースのコミュニティバージョンがあります。シンプルなプランが完成しました:

オートコンプリートを担当するソースコード内のクラスを見つける
外部メタデータを操作するようにそれらをリダイレクトし、そこから結合に関する情報を取得します。
？
利益

最初の点はすぐに理解できました。バグトラッカーで自動入力を調整するリクエストと関連するリクエストを見つけました。専念 SQLCompletionAnalyzer クラスを発見しました。コードを見たところ、それが必要なものでした。残っているのは、すべてが機能するように書き直すことだけです。私は夜が空くのを待って、実装についてじっくり考え始めました。テーブルのリンクルール（メタデータ）をjsonで書くことにしました。私にはこのフォーマットを使った実務経験がなかったので、今回のタスクはこの欠落を修正する機会と見なされていました。

jsonを扱うためにライブラリを使用することにしました json-simple Googleから。ここから驚きが始まりました。実際のアプリケーションとしての dbeaver は、OSGi フレームワークを使用して Eclipse プラットフォーム上で作成されたことが判明しました。経験豊富な開発者にとって、これは依存関係の管理に便利ですが、私にとっては、明らかに準備ができていなかった黒魔術のようなものでした。いつものように、ヘッダーの json-simple ライブラリから必要なクラスをインポートします。編集したクラスを pom.xml で指定すると、プロジェクトは通常のアセンブルを断固として拒否し、エラーでクラッシュします。

最終的に、ビルドエラーを修正することができました。ライブラリを 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>

その結果、私は変更を加えた SQLUtils クラスと SQLCompletionAnalyzer クラスに追加します。考え方は次のとおりです。プログラムが基本ロジックを使用して適切なオートコンプリート候補を見つけることができなかった場合、外部 XML ファイルを使用して可能な結合の存在をチェックします。ファイル自体には、これらのテーブルをリンクする必要があるフィールドを示すテーブルのペアが格納されます。レコード eff_dttm および exp_dttm の技術的有効期限と論理削除フラグ delete_ind に関する制限がデフォルトで設定されています。

コードに変更が加えられたとき、誰がファイルにメタデータを書き込むのかという疑問が生じました。リポジトリには多数のエンティティがあり、すべての接続を自分で登録するにはコストがかかります。その結果、私はこのタスクを同僚のアナリストに割り当てることにしました。メタデータファイルを svn で投稿し、そこからプログラムでローカルディレクトリにチェックアウトが行われます。原則は次のとおりです。新しいエンティティがリポジトリに出現したか? XNUMX 人のアナリストが結合の可能性をファイルに入力し、変更をコミットします。残りのアナリストは自分自身でチェックアウトし、機能するオートコンプリートを楽しみます。コミュニティ、知識の蓄積などです。同僚向けにプログラムの使用に関するワークショップを実施し、Confluence で記事を書きました。現在、会社にはさらに便利なツールが XNUMX つあります。

この機能に取り組むことで、オープンソースプロジェクトをいじることを恐れる必要はないということがわかりました。一般に、オープンソースプロジェクトには明確なアーキテクチャがあり、実験には言語の基本的な知識さえあれば十分です。また、ある程度の粘り強さがあれば、嫌いなルーチン操作をなくすこともでき、新しい実験に費やす時間を節約することもできます。

出所： habr.com

同じことをやめる方法

コメントを追加します 返信をキャンセル

コメントを追加します返信をキャンセル