经过连续几期的介绍，《手写 SQL 编译器》系列进入了 “智能提示” 模块，前几期从 词法到文法、语法，再到构造语法树，错误提示等等，都是为 “智能提示” 做准备。

为了更清晰展现逻辑层次，同时满足解耦的要求，笔者先从智能提示整体设计架构讲起。

1

select | from b;

你会发现，从语法和提示角度来看同一个输入，结果往往是矛盾的， 所以我们需要分两条线程分别处理语法与提示。

但输入错误时，我们是无法构造语法树的，而智能提示的时机往往都是语句语法错误的时机 ，用过 AST 工具的人都知道。可是没有语法树，我们怎么做到智能的提示呢？试想如下语句：

1
2
3

select c.| from (
  select * from dt;
) c;

面对上面这个语句，很显然 c. 没有写完，一般的语法树解析器提示你语法错误。你可能想到这几种方案：

一般我们会采取第二种方案，看上去相对靠谱。处理过程是这样的：

1

select c.$my_custom_symbol$ from ...

之后在 AST 中找到 $my_custom_symbol$ 字符串，对应的节点就是光标位置。 实际上这可以解决大部分问题，除了关键字。

这种方案唯有关键字场景不兼容，试想一下：

1
2

select a |from b;
## select a $my_custom_symbol$ from b;

你会发现，“补全光标文字” 法，在关键字位置时，会把原本正确的语句变成错误的语句，根本解析不出语法树。

我们在 syntax-parser 解析引擎层就解决了这个问题，解决方案是 连同光标位置一起解析。

因此针对第一种假设，syntax-parser 内置了 “关键字提示” 功能。因为 syntax-parser 可以拿到你配置的文法，因此当给定光标位置时，可以拿到当前位置前一个 Token，通过回溯和平行尝试，将后面所有可能性提示出来，如下图：

输入是 select a | ，灰色部分是已经匹配成功的部分，而我们发现光标位置前一个 Token 正是红色标识的 word ，通过尝试运行推导，我们发现，桔红色标记的 ',' 和 'from' 都是 word 可能的下一个确定单词，这种单词就是 SQL 语法中的 “关键字”，syntax-parser 会自动告诉你，光标位置可能的输入是 [',', 'from'] 。

所以关键字的提示已经在 syntax-parser 层内置解决了！而且无论语法正确与否，都不影响提示结果，因为算法是 “寻找光标位置前一个 Token 所有可能的下一个 Token”，这可以完全由词法分析器内置支持。

非关键字：

针对非关键字，我们解决方案和用特殊字符串补充类似，但也有不同：

因此 syntax-parser 总是返回两个 AST 信息：

1
2
3
4

{
  "ast": {},
  "cursorPath": []
}

分别是语法树详细信息，与光标位置在语法树中的访问路径。

对于 select a | 的情况，会生成三个 Tokens： ['select', 'a', 'cursor'] ，对于 select a| 的情况，会生成两个 Tokens： ['select', 'a'] ，也就是光标与字符相连时，不会覆盖这个字符。

cursorPath 的生成也比 “字符串补充” 方案更健壮，syntax-parser 生成的 AST 会记录每一个 Token 的位置，最终会根据光标位置进行比对，进而找到光标对应语法树上哪个节点。

对 .| 的处理：

可能你已经想到了， .| 情况是很通用的输入场景，比如 user. 希望提示出 user 对象的成员函数，或者 SQL 语句表名存在项目空间的情况，可能 tableName 会存在 .| 的语法。

.| 状况时，语法是错误的，此时智能提示会遇到挑战。根据查阅的资料，这块也有两种常见处理手法：

然而这两种方式都不太优雅，syntax-parser 选择了第三种方式：隔空打牛。

通过抽象，我们发现，无论是 user.name 还是 udf:count() 这种语法，都要求在某个制定字符打出时（比如 . 或 : ），提示到这个字符后面跟着的 Token。

此时光标焦点在 . 而非之后的字符上， 那我们何不将光标偷偷移到 . 之后，进行空光标 Token 补位呢！ 这样不但能完全复用之前的处理思想，还可以拿到我们真正想拿到的位置：

1
2

select a(.|) from b;
## select a. (|) from b

对比后发现，第一行拥有 4 个 Token，语法错误，而经过修改的第二行拥有 5 个 Token（一个光标补位），语法正确，且光标所在位置等价于第一行我们希望提示的位置，此问题得以解决。

1
2
3
4

CREATE TABLE dwd_log_pv_wl_ri(
  PRIMARY KEY(rowkey),
  PERIOD FOR SYSTEM_TIME
) WITH ()

要支持这种语法，我们在非终结符 tableOption 下增加两个分支即可：

1
2
3
4
5
6

const tableOption = () =>
  chain([
    chain(stringOrWord, dataType)(),
    chain("primary", "key", "(", primaryKeyList, ")")(),
    chain("period", "for", "system_time")()
  ])();

sql-reader：

为了方便解析 SQL 语法树，我们在 sql-reader 内置了几个常用方法，比如：

有了 sql-reader，我们可以保证在这种层层嵌套 + 别名混淆 + select * 这种复杂的场景下，仍然能追溯到字段的最原始名称，最原始的表名：

这样上层业务拓展时，可以拿到足够准、足够多的信息，具有足够好的拓展型。

monaco-editor plugin：

我们也支持了更上层的封装，Monaco Editor 插件级别的，只需要填一些参数：获取表名、获取字段的回调函数就能 Work，统一了内部业务的调用方式：

1
2
3
4
5
6
7
8
9
10
11
12

import { monacoSqlAutocomplete } from '@alife/monaco-sql-plugin';

// Get monaco and editor.

monacoSqlAutocomplete(monaco, editor, {
  onInputTableField: async tableName => { // ...},
  onInputTableName: async () => { // ... },
  onInputFunctionName: async () => { // ... },
  onHoverTableName: async cursorInfo => { // ... },
  onHoverTableField: (fieldName, extra) => { // ... },
  onHoverFunctionName: functionName => { // ... }
});

比如实现了 onInputTableField 接口，我们可以拿到当前表名信息，轻松实现字段提示：

你也许会看到，上图中鼠标位置有错误提示（红色波浪线），但依然给出了正确的推荐提示。 这得益于我们对 syntax-parser 内部机制的优化，将语法检查与智能提示分为两个模块独立处理，经过语法解析，虽然抛出了语法错误，但因为有了光标的加入，最终生成了语法树。

再比如实现了 onHoverFunctionName ，可以自定义鼠标 hover 在函数时的提示信息：

得益于 sql-reader ，我们对 sql 语句做了层层解析，所以才能把自动提示做到极致。比如在做字段自动提示时，经历了如下判断步骤：

而你只需要实现 onInputTableField ，告诉程序每个表可以提供哪些字段，整个流程就会严格的层层检查表名提供对原始字段与 selectList 描述的输出字段，找到映射关系并逐级传递、校验，最终 Merge 后一直冒泡到当前光标位置所在语句，形成输入建议。