🥇如何停止做同樣的事情

您喜歡一遍又一遍地重複日常操作嗎？所以我不。但每次在 SQL 用戶端中使用 Rostelecom 儲存時，我都必須手動註冊表之間的所有連線。儘管事實上在 90% 的情況下，連接表的欄位和條件在查詢之間是一致的！似乎任何SQL 用戶端都有自動完成功能，但對於儲存來說，它並不總是有效：它們很少包含唯一約束和外鍵以提高效能，如果沒有這個，程式將不知道實體如何與每個實體相關。其他以及它能為您提供什麼。

在經歷了否認、憤怒、討價還價、沮喪和接近接受之後，我決定 - 為什麼不嘗試自己實現二十一點自動填充並以正確的方式進行呢？我使用dbeaver客戶端，用java編寫，它有一個開源社群版本。一個簡單的計劃已經成熟：

在原始程式碼中尋找負責自動完成的類
重定向它們以使用外部元數據並從那裡提取有關連接的信息
？？？
除

我很快就弄清楚了第一點 - 我在錯誤追蹤器中找到了調整自動填充的請求以及相關的請求犯罪發現了 SQLCompletionAnalyzer 類別。我查看了程式碼，這就是我需要的。剩下的就是重寫它，以便一切正常。我等待一個空閒的夜晚，開始思考實施方案。我決定用json寫表格連結規則（元資料）。我沒有使用這種格式的實際經驗，目前的任務被視為糾正這一遺漏的機會。

為了使用 json，我決定使用該函式庫 json-簡單來自Google。這就是驚喜的開始。事實證明，dbeaver 作為一個真正的應用程序，是使用 OSGi 框架在 Eclipse 平台上編寫的。對於經驗豐富的開發人員來說，這個東西可以方便地管理依賴項，但對我來說，這更像是黑暗魔法，我顯然還沒有準備好：像往常一樣，我從json-simple 庫的標頭中導入我需要的類編輯後的類，在 pom.xml 中指定它，之後專案斷然拒絕正常組裝並因錯誤而崩潰。

最後，我設法修復了建置錯誤：我按照 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>

結果我做了改變進入 SQLUtils 和 SQLCompletionAnalyzer 類別。這個想法是這樣的：如果程式無法使用基本邏輯找到合適的自動完成建議，那麼它會使用外部 xml 檔案檢查是否有可能的連線。文件本身儲存成對的表，指示需要連結這些表的欄位。預設設定對記錄 eff_dttm 和 exp_dttm 的技術有效日期以及邏輯刪除標誌deleted_ind 的限制。

當對程式碼進行更改時，出現了問題 - 誰會用元資料填充檔案？儲存庫中有很多實體，自己註冊所有連線的成本很高。因此，我決定將這項任務分配給我的分析師同事。我在 svn 中發布了元資料文件，從那裡用程式簽出到本地目錄。原理是這樣的：儲存庫中是否出現了新的實體？一名分析師將可能的連接輸入到文件中，提交更改，其餘的分析師自行檢查並享受工作自動完成：社區、知識累積等等。為同事舉辦了一個關於使用該程式的研討會，在 Confluence 上寫了一篇文章 - 現在公司有了一個更方便的工具。

開發此功能讓我認識到不必害怕修改開源專案 - 一般來說，它們具有清晰的架構，甚至語言的基本知識也足以進行實驗。只要有一定的毅力，您甚至可以擺脫討厭的常規操作，從而節省時間進行新的實驗。

來源： www.habr.com

如何停止做同樣的事情

添加評論 取消回复

添加評論取消回复