作者 | ChangJin Wei（魏昌進(jìn)）

小T導(dǎo)讀：本文是一篇來自 TDengine 社區(qū)的原創(chuàng)投稿。作者基于自身在 JetBrains IDEs 中使用 TDengine 的實際需求，獨立開發(fā)并開源了相關(guān)插件，用于增強(qiáng) TDengine 在 JetBrains 數(shù)據(jù)庫工具鏈中的接入與 SQL 開發(fā)體驗。我們很高興看到，越來越多開發(fā)者正在從真實需求出發(fā)，為 TDengine 生態(tài)帶來更豐富、更實用的補(bǔ)充。今天將這篇文章分享給大家，也期待更多來自社區(qū)的實踐與聲音。

最近我做了一個小插件，把 TDengine 接入到了 JetBrains IDEs 的數(shù)據(jù)庫工具鏈里。

先埋個小提示：文末有彩蛋。

項目地址：

? GitHub：https://github.com/galaxy-sea/TDengine-Driver-Integration

? JetBrains Plugin Marketplace：https://plugins.jetbrains.com/plugin/30538-tdengine-driver-integration

寫這個插件的起因其實很直接。

我平時更習(xí)慣在 JetBrains IDEs 里處理數(shù)據(jù)庫相關(guān)工作，尤其是 DataGrip 這一套交互邏輯已經(jīng)用順手了。對于 MySQL、PostgreSQL、ClickHouse 這類 JetBrains 已經(jīng)支持得比較完整的數(shù)據(jù)庫，連庫、寫 SQL、看對象定義、做補(bǔ)全，整個過程都比較流暢。但一旦切到 TDengine，體驗就會突然斷層。

不是說不能用，而是“不順”。要么是驅(qū)動和連接參數(shù)要自己折騰，要么是 SQL 編輯體驗不完整；再加上其他數(shù)據(jù)庫管理工具的交互邏輯和 JetBrains IDEs 并不完全一樣，來回切換時總會有一種“工具在遷就數(shù)據(jù)庫，而不是數(shù)據(jù)庫融入工具”的感覺。

所以我當(dāng)時的想法很簡單：能不能讓 TDengine 在 JetBrains IDEs 里，至少先擁有接近原生數(shù)據(jù)庫的基礎(chǔ)體驗？

一開始，真正難的不是寫代碼

真正開始動手以后，我很快發(fā)現(xiàn)，最難的部分并不是“把功能寫出來”，而是“搞清楚應(yīng)該怎么寫”。

原因主要有兩個。

第一，JetBrains Database 插件開發(fā)資料很少。常規(guī) IntelliJ Platform 插件還能找到不少示例和文章，但一旦具體到 database 模塊、數(shù)據(jù)源注冊、元數(shù)據(jù)包裝、方言掛載這些問題，能參考的內(nèi)容就明顯少很多。很多時候只能對著現(xiàn)象試、對著 API 猜，或者直接進(jìn)源碼里一點點摸。

第二，關(guān)于 PSI 方言設(shè)計的資料也不多。尤其是 TDengine 這種并不是完全照搬某個主流數(shù)據(jù)庫方言的場景，語法該怎么拆、哪些 token 應(yīng)該視為關(guān)鍵字、哪些應(yīng)該進(jìn)入函數(shù)調(diào)用鏈路，這些都需要自己整理。

換句話說，真正的門檻不是“插件開發(fā)”，而是“在缺少現(xiàn)成路徑的情況下，把這套東西自己走通”。

中間最卡的三個問題

如果要總結(jié)這次開發(fā)過程中最卡的三個問題，我會歸納成下面這三個。

1. TDengine 方言的 PSI 設(shè)計

這是最核心、也最容易反復(fù)返工的一塊。

JetBrains 的 SQL 能力很多都建立在 PSI 結(jié)構(gòu)之上。語法樹設(shè)計得不穩(wěn)，后面的補(bǔ)全、高亮、參數(shù)提示、文檔提示，基本都會跟著變形?？雌饋硐袷恰爸皇且粋€函數(shù)沒高亮”，本質(zhì)上往往是語法分類錯了。

比如 TDengine 里有些內(nèi)容既像關(guān)鍵字又像函數(shù)，有些寫法既支持裸寫也支持帶括號調(diào)用。如果一開始 PSI 設(shè)計沒把這類情況理順，后續(xù)處理會非常痛苦。

這部分我花了不少時間反復(fù)調(diào)整，因為它不是單點功能，而是整條鏈路的地基。

2. TDengine 方言的整理和歸納

寫方言不是簡單把關(guān)鍵字表貼進(jìn)去就結(jié)束了。

真正麻煩的是整理規(guī)則：哪些屬于關(guān)鍵字，哪些屬于內(nèi)建函數(shù)，哪些是特殊語法，哪些雖然看起來像函數(shù)但又不完全適合按普通函數(shù)處理。只要歸類模糊，最后表現(xiàn)出來就會是補(bǔ)全不一致、高亮不一致、某些語句能過某些語句不能過。

這個過程更像是在做“方言工程化整理”，而不是單純寫解析器。尤其當(dāng)你想把體驗做成“像 JetBrains 原生支持的數(shù)據(jù)庫一樣”時，對一致性的要求會更高。

3. TDengine 方言的回歸測試

這個問題一開始其實容易被低估。

方言適配最怕的不是“有 bug”，而是“你修了一個點，又把另一個點帶壞了”。今天修了函數(shù)高亮，明天可能影響補(bǔ)全；今天讓一種寫法能過解析，明天可能把另一種寫法沖掉。

而 TDengine 的語法適配又涉及 lexer、parser、PSI、completion、documentation、live templates 這些不同層次，回歸驗證的成本不低。很多時候不是寫完就行，而是你得想清楚這次改動到底影響了哪一層。

這也讓我更明確了一件事：方言適配不能只追求“先能用”，還得盡量控制后續(xù)回退成本。

最后做成了什么

到目前為止，這個插件優(yōu)先完成的是兩件事：連接體驗和 SQL 開發(fā)體驗。

在連接層面，插件提供了 TDengine 數(shù)據(jù)源入口、內(nèi)置 JDBC 版本列表、連接參數(shù)模板和配置校驗。也就是說，用戶在 JetBrains IDEs 里添加 TDengine 數(shù)據(jù)源時，不需要再從零開始拼接配置，整體路徑會更接近 JetBrains 已支持?jǐn)?shù)據(jù)庫的使用方式。

在 SQL 開發(fā)層面，目前已經(jīng)完成了 TDengine 方言的基礎(chǔ)適配，包括：

? TDengine 數(shù)據(jù)源接入

? JDBC 驅(qū)動版本選擇與下載

? 連接配置校驗

? SQL 方言支持

? 關(guān)鍵字補(bǔ)全

? 函數(shù)補(bǔ)全

? 函數(shù)高亮

? 函數(shù)參數(shù)提示

? 函數(shù)懸停文檔

? Live Templates

對我來說，這里面最重要的不是某一個單獨功能，而是整體交互邏輯終于開始“像一門被 JetBrains IDEs 認(rèn)真支持的數(shù)據(jù)庫”了。

這也是我最想做成的效果：當(dāng)你在 JetBrains IDEs 里操作 TDengine 時，不再明顯感覺自己在使用一套“勉強(qiáng)接上去”的能力，而是盡量貼近已經(jīng)熟悉的數(shù)據(jù)庫工作流。

還有哪些沒做完

目前優(yōu)先完成的是連接與 SQL 開發(fā)體驗，GUI DDL 適配仍在推進(jìn)中。

更直接一點說，現(xiàn)在主要還是把“寫 SQL、連庫、看提示”這條主鏈路先打通了；至于 GUI 側(cè)的表創(chuàng)建、字段修改這類能力，還沒有完全做完。

這部分之所以還在推進(jìn)中，不是因為價值低，而是因為它和數(shù)據(jù)庫工具內(nèi)部的數(shù)據(jù)模型、元數(shù)據(jù)行為綁定得更深，處理起來比表面看上去復(fù)雜得多。后續(xù)如果繼續(xù)迭代，我也會優(yōu)先把這些 GUI 操作補(bǔ)齊。

為什么我覺得這件事值得做

我一直覺得，一個數(shù)據(jù)庫生態(tài)是否成熟，不只取決于服務(wù)端和驅(qū)動本身，也取決于它能不能自然地進(jìn)入開發(fā)者已經(jīng)習(xí)慣的工作環(huán)境。

很多時候，開發(fā)者并不是缺一個“能連接 TDengine 的工具”，而是缺一個“能讓 TDengine 融入現(xiàn)有工作流的工具”。如果一門數(shù)據(jù)庫在常見 IDE 里始終缺少順手的支持，那它在很多場景里就會天然增加使用門檻。

這個插件現(xiàn)在當(dāng)然還談不上完美，但至少它在一個很具體的問題上往前走了一步：讓 TDengine 在 JetBrains IDEs 里，開始變得更自然一些。

如果這篇文章能讓更多 TDengine 用戶少走一點彎路，或者讓更多開發(fā)者愿意一起補(bǔ)齊 JetBrains 生態(tài)里的 TDengine 支持，我覺得這件事就已經(jīng)很值得了。

最后的彩蛋

對多語言開發(fā)場景來說，這次還有一個額外收益。

如果你的項目本身就在 JetBrains IDEs 里使用 MyBatis 相關(guān)插件，那么在 XML 中編寫 TDengine SQL 時，也可以聯(lián)動獲得語法提示體驗。換句話說，Java MyBatis 生態(tài)的兄弟們也有福了，XML 里的 TDengine SQL 不再只能“盲寫”。

更進(jìn)一步說，這個收益也不局限于 MyBatis、Java，甚至不局限于某一個固定框架。只要所在語言或框架支持 JetBrains IDEs 的語言注入能力，例如 @Language("SQL")、//language=SQL 或類似機(jī)制，就可以把字符串里的 TDengine SQL 交給 IDE 識別，從而獲得接近的補(bǔ)全和提示體驗。

這不是一個單獨做出來的“宣傳點”，而是 TDengine 方言能力接入 JetBrains IDEs 之后，自然帶出來的一個實用效果。對日常維護(hù) XML SQL 或嵌入式 SQL 的項目來說，這一點會非常省心。