Page History

...

我们计划为每种查询类型新建一个逻辑运算符，如为 Group by 新建 GroupByQueryOperator，以此方便之后物理计划生成的重构，即将物理计划生成放在不同种类的逻辑运算符内完成。

此前，是按照 此前，是按照 SELECT -> FROM -> WHERE -> SpecialClause 的顺序进行解析，这显然不再合理，因为没办法提前知道由第四部分决定的查询类型。

因此，计划将解析顺序改为，因此，计划将解析顺序改为，SpecialClause -> SELECT -> FROM -> WHERE，这种解析顺序可以提前知道每一种查询的类型并新建该逻辑运算符。

接下来看由第一部分确定的 4 个查询：

首先明确一个概念，QueryOperator 此前，QueryOperator 继承自 SFWOperator。

其中有三个成员变量，SelectOperator，FromOperator 和 FilterOperator。

...

SFWOperator 的继承类包括：

以 DeleteOperator 为例：

Image Removed

为例，其只是为了利用 SelectOperator 中的前（后）缀路径。

这显然是当时设计的时候图省事，就直接让这几个类继承 SFW 了。SFWOperator 还有对于 Where 子句中过滤条件的优化，这是 Insert、Delete 等运算符根本没必要去跑的。

Image Removed

因此，这些类可以从 SFWOperator 的子类中分离出来。（这部分交给宇荣去做了）

因此，这些类可以从 SFWOperator 的子类中分离出来。（这部分交给宇荣去做了）此时，SFWOperator 就可以直接干掉，其中的成员变量直接拿到 QueryOperator 内。因为其只有一个子类为 内。因为其只有一个子类为 QueryOperator.

我们继续来看查询部分。

此前，普通查询中 此前，普通查询中 SELECT 子句中的后缀路径，聚合查询中的聚合函数等信息是存储在SFWOperator内的 SelectOperator 内的，而不是存储在 QueryOperator 内里。

Image RemovedImage Added

这部分中的后缀路径、聚合函数、UDF及算数表达式等信息，都会被包装为一个 计划中，将这部分中的后缀路径、聚合函数、UDF及算数表达式等信息包装为一个 List<ResultColumn> 的一个 List，其中相关操作都会在ResultColumn 内部完成，我们暂时不关心内部实现。 内部完成。

Image Added

于是，由第一部分决定的查询类型对外暴露的 SelectComponent 是相同的，只有 SelectComponent 内部的 ResultColumn 类型不同。

这个在读取到第一个 Select 元素时就可以进行判断，并生成对应的查询类型。

同理，由第四部分决定的查询类型对外暴露的只有 SpecialClauseCompoent 不同。

因此，修改后QueryOperator主要内容如下：

Image Added

于是最后 最后 QueryOperator 的类图为：

QueryOperator主要内容如下：

Image Removed

这里由于 Select、From 等只用来存储内容，并没有逻辑运算符的特性，因此其不应该继承 Operator，于是重新命名为 XxxComponent。

SpecialClauseCompent 的类图为：