您喜歡一遍又一遍地重複日常操作嗎? 所以我不。 但每次在 SQL 用戶端中使用 Rostelecom 儲存時,我都必須手動註冊表之間的所有連線。 儘管事實上在 90% 的情況下,連接表的欄位和條件在查詢之間是一致的! 似乎任何SQL 用戶端都有自動完成功能,但對於儲存來說,它並不總是有效:它們很少包含唯一約束和外鍵以提高效能,如果沒有這個,程式將不知道實體如何與每個實體相關。其他以及它能為您提供什麼。
在經歷了否認、憤怒、討價還價、沮喪和接近接受之後,我決定 - 為什麼不嘗試自己實現二十一點自動填充並以正確的方式進行呢? 我使用dbeaver客戶端,用java編寫,它有一個開源社群版本。 一個簡單的計劃已經成熟:
- 在原始程式碼中尋找負責自動完成的類
- 重定向它們以使用外部元數據並從那裡提取有關連接的信息
- ???
- 除
我很快就弄清楚了第一點 - 我在錯誤追蹤器中找到了調整自動填充的請求以及相關的請求
為了使用 json,我決定使用該函式庫
最後,我設法修復了建置錯誤:我按照 OSGI 的要求,不在 pom.xml 中註冊庫,而是在 manifest.mf 清單中註冊庫,同時將其指定為 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 中發布了元資料文件,從那裡用程式簽出到本地目錄。 原理是這樣的:儲存庫中是否出現了新的實體? 一名分析師將可能的連接輸入到文件中,提交更改,其餘的分析師自行檢查並享受工作自動完成:社區、知識累積等等。 為同事舉辦了一個關於使用該程式的研討會,在 Confluence 上寫了一篇文章 - 現在公司有了一個更方便的工具。
開發此功能讓我認識到不必害怕修改開源專案 - 一般來說,它們具有清晰的架構,甚至語言的基本知識也足以進行實驗。 只要有一定的毅力,您甚至可以擺脫討厭的常規操作,從而節省時間進行新的實驗。
來源: www.habr.com