[翻译]DSQL/BLR实现内幕

这是Adriano dos Santos Fernandes写在自己博客的一篇关于Firebird 的DSQL/BLR重构/重写的一些背景和实现内幕。

原文为:DSQL/BLR compilers internals

这个贴子的内容是一些原始笔记,没有研究过这些代码的人不太好理解。

说实话,以前DSQL/BLR的实现是如此恶心,以至于要实现改进对我也不是件容易的事(我一直从事这个事)。这需要多次的尝试和重新来过,但还好结果总是非常好。可以说,这是个花费许多时间的大工程,我也是现在才在这写些笔记。

回想2006,我刚被邀请从事DSQL方面工作时,我开始思考我们应该做些什么来改进DSQL和BLR的内部编译。我开始从

src/dsql/pass1.cpp

src/jrd/cmp.cpp

进行研究。那之前,增加一个简单的函数功能也是一个噩梦。下面的对话是Nickolay Samofatov 和我在2004年9月进行的:

Adriano: 我增加了“Lower”函数,我没想到这活这么麻烦。“Length”函数也要通过BLR加进来么?
Nickolay: 怎么会麻烦呢?
Nickolay: 只是调整15个左右的文件 :-) 

从那后我好几年都在调整“15个左右的文件”来增加每个功能,这过程非常烦人。在2.5版,为了实现 ALTER CHARACTER SET 和 AUTONOMOUS TRANSACTIONS 语句语法,我增加了“兼容层”来以更加面象对象的方式来实现这些语句语法。我在这个贴子中描述了DDL是如何工作的。

如我在那贴子中承诺的那样,这个功能将实现子函数,以及包(packages)功能。

在Firebird V3开发过程后,很显然,不仅是语句需要这个“兼容层”,表达式也是一样。而且表达式相比语句而言对于“兼容层”更加“感兴趣”。Firebird中有许多类型表达式,它们都错落地分布在dsqlnod/jrdnod结构和各类算法中(现在这个现象不存在了)。这些类型是:record sources, values, booleans, aggregate values, windowed values 和 lists。

表达式兼容层设计成实现window函数(更多信息请查看这里这里这里),但同时它产生了更多糟糕的内部接口代码。

完整地移除jrdnod很容易,并在很早以前就完成了。但dsqlnod还留着。它有许多代码需要完全重构(或重写),现在这些工作都完成了。

下面是Node类的继承关系。除了列表中的,每个都有自己的继承类(这里忽略了)。

Node
--- DdlNode
--- DmlNode
------ StmtNode
------ ExprNode
--------- BoolExprNode
--------- ValueExprNode
------------ AggNode
--------------- WinFuncNode
--------- RecordSourceNode
--------- ListExprNode
------------ ValueListExprNode
------------ RecSourceListExprNode

正如我所说过的,这里花费了大量的时间,但如果没有花费这些时间许多其它功能就不可能实现或无实现价值了。

现在可以轻松地说老代码是垃圾(这是事实,真的!),但许多事都是相关并逐渐演进的(C和C++,bison和btyacc)。重要的是返工的时机到了,所以这项工作就被完成了。

标签: firebird, DSQL, BLR, 翻译

添加新评论