让 TDengine 在 JetBrains IDEs 里更像“原生数据库”一点Author: ChangJin Wei (魏昌进)最近我做了一个小插件把 TDengine 接入到了 JetBrains IDEs 的数据库工具链里。先埋个小提示文末有彩蛋。项目地址GitHub: https://github.com/galaxy-sea/TDengine-Driver-IntegrationJetBrains Plugin Marketplace: https://plugins.jetbrains.com/plugin/30538-tdengine-driver-integration写这个插件的起因其实很直接。我平时更习惯在 JetBrains IDEs 里处理数据库相关工作尤其是 DataGrip 这一套交互逻辑已经用顺手了。对于 MySQL、PostgreSQL、ClickHouse 这类 JetBrains 已经支持得比较完整的数据库连库、写 SQL、看对象定义、做补全整个过程都比较流畅。但一旦切到 TDengine体验就会突然断层。不是说不能用而是“不顺”。要么是驱动和连接参数要自己折腾要么是 SQL 编辑体验不完整再加上其他数据库管理工具的交互逻辑和 JetBrains IDEs 并不完全一样来回切换时总会有一种“工具在迁就数据库而不是数据库融入工具”的感觉。所以我当时的想法很简单能不能让 TDengine 在 JetBrains IDEs 里至少先拥有接近原生数据库的基础体验一开始真正难的不是写代码真正开始动手以后我很快发现最难的部分并不是“把功能写出来”而是“搞清楚应该怎么写”。原因主要有两个。第一JetBrains Database 插件开发资料很少。常规 IntelliJ Platform 插件还能找到不少示例和文章但一旦具体到 database 模块、数据源注册、元数据包装、方言挂载这些问题能参考的内容就明显少很多。很多时候只能对着现象试、对着 API 猜或者直接进源码里一点点摸。第二关于 PSI 方言设计的资料也不多。尤其是 TDengine 这种并不是完全照搬某个主流数据库方言的场景语法该怎么拆、哪些 token 应该视为关键字、哪些应该进入函数调用链路这些都需要自己整理。换句话说真正的门槛不是“插件开发”而是“在缺少现成路径的情况下把这套东西自己走通”。中间最卡的三个问题如果要总结这次开发过程中最卡的三个问题我会归纳成下面这三个。1. TDengine 方言的 PSI 设计这是最核心、也最容易反复返工的一块。JetBrains 的 SQL 能力很多都建立在 PSI 结构之上。语法树设计得不稳后面的补全、高亮、参数提示、文档提示基本都会跟着变形。看起来像是“只是一个函数没高亮”本质上往往是语法分类错了。比如 TDengine 里有些内容既像关键字又像函数有些写法既支持裸写也支持带括号调用。如果一开始 PSI 设计没把这类情况理顺后续处理会非常痛苦。这部分我花了不少时间反复调整因为它不是单点功能而是整条链路的地基。2. TDengine 方言的整理和归纳写方言不是简单把关键字表贴进去就结束了。真正麻烦的是整理规则哪些属于关键字哪些属于内建函数哪些是特殊语法哪些虽然看起来像函数但又不完全适合按普通函数处理。只要归类模糊最后表现出来就会是补全不一致、高亮不一致、某些语句能过某些语句不能过。这个过程更像是在做“方言工程化整理”而不是单纯写解析器。尤其当你想把体验做成“像 JetBrains 原生支持的数据库一样”时对一致性的要求会更高。3. TDengine 方言的回归测试这个问题一开始其实容易被低估。方言适配最怕的不是“有 bug”而是“你修了一个点又把另一个点带坏了”。今天修了函数高亮明天可能影响补全今天让一种写法能过解析明天可能把另一种写法冲掉。而 TDengine 的语法适配又涉及 lexer、parser、PSI、completion、documentation、live templates 这些不同层次回归验证的成本不低。很多时候不是写完就行而是你得想清楚这次改动到底影响了哪一层。这也让我更明确了一件事方言适配不能只追求“先能用”还得尽量控制后续回退成本。最后做成了什么到目前为止这个插件优先完成的是两件事连接体验和 SQL 开发体验。在连接层面插件提供了 TDengine 数据源入口、内置 JDBC 版本列表、连接参数模板和配置校验。也就是说用户在 JetBrains IDEs 里添加 TDengine 数据源时不需要再从零开始拼接配置整体路径会更接近 JetBrains 已支持数据库的使用方式。在 SQL 开发层面目前已经完成了 TDengine 方言的基础适配包括TDengine 数据源接入JDBC 驱动版本选择与下载连接配置校验SQL 方言支持关键字补全函数补全函数高亮函数参数提示函数悬停文档Live Templates对我来说这里面最重要的不是某一个单独功能而是整体交互逻辑终于开始“像一门被 JetBrains IDEs 认真支持的数据库”了。这也是我最想做成的效果当你在 JetBrains IDEs 里操作 TDengine 时不再明显感觉自己在使用一套“勉强接上去”的能力而是尽量贴近已经熟悉的数据库工作流。还有哪些没做完目前优先完成的是连接与 SQL 开发体验GUI DDL 适配仍在推进中。更直接一点说现在主要还是把“写 SQL、连库、看提示”这条主链路先打通了至于 GUI 侧的表创建、字段修改这类能力还没有完全做完。这部分之所以还在推进中不是因为价值低而是因为它和数据库工具内部的数据模型、元数据行为绑定得更深处理起来比表面看上去复杂得多。后续如果继续迭代我也会优先把这些 GUI 操作补齐。为什么我觉得这件事值得做我一直觉得一个数据库生态是否成熟不只取决于服务端和驱动本身也取决于它能不能自然地进入开发者已经习惯的工作环境。很多时候开发者并不是缺一个“能连接 TDengine 的工具”而是缺一个“能让 TDengine 融入现有工作流的工具”。如果一门数据库在常见 IDE 里始终缺少顺手的支持那它在很多场景里就会天然增加使用门槛。这个插件现在当然还谈不上完美但至少它在一个很具体的问题上往前走了一步让 TDengine 在 JetBrains IDEs 里开始变得更自然一些。如果这篇文章能让更多 TDengine 用户少走一点弯路或者让更多开发者愿意一起补齐 JetBrains 生态里的 TDengine 支持我觉得这件事就已经很值得了。看到最后的彩蛋让我们来个骚操作吧对多语言开发场景来说这次还有一个额外收益。如果你的项目本身就在 JetBrains IDEs 里使用 MyBatis 相关插件那么在 XML 中编写 TDengine SQL 时也可以联动获得语法提示体验。换句话说Java MyBatis 生态的兄弟们也有福了XML 里的 TDengine SQL 不再只能“盲写”。更进一步说这个收益也不局限于 MyBatis、Java甚至不局限于某一个固定框架。只要所在语言或框架支持 JetBrains IDEs 的语言注入能力例如Language(SQL)、//languageSQL或类似机制就可以把字符串里的 TDengine SQL 交给 IDE 识别从而获得接近的补全和提示体验。这不是一个单独做出来的“宣传点”而是 TDengine 方言能力接入 JetBrains IDEs 之后自然带出来的一个实用效果。对日常维护 XML SQL 或嵌入式 SQL 的项目来说这一点会非常省心。