[SDU软件工程实践]Blog7-迈入compile

2021SC@SDUSC

• 遗留问题：txn
• compile
• 对Antrl

上次我们留下了一个问题：这个txn是什么概念？为什么它可能导致compileInternal再次被调用？

其实最直接的还是看这个方法本身的注释。txn是一个与事务、锁等有关的概念1，这个方法也是检查事务相关内容的，产生冲突时返回false。而且与之相关的queryTxnMgr，是一个HiveTxnManager对象。这个类（接口）是用于事务管理的（来源是hive官方文档）。

queryTxnMgr的用法中，只有两个是设置值的。而这两个设置值的位置都在compile方法内。所以，基于相关概念与事务管理有关，我们可以先判断它不会影响到编译、HQL解析等步骤，然后在阅读compile的过程中注意一下。

我们现在有资格开始看compile了。这个方法非常非常的长，且极有可能涉及到了不属于我的那部分。
我们首先来看这一段

command这个变量就是之前一路向下传的“单条完整的HQL指令”。而这里是进行了一个称之为“变量代换”的操作。
substitute方法进行了几重调用，我们直接看最后的。

match是用于正则表达式匹配字符串的，匹配用的字符串是这样的

涉及到java本身"“就是转义用的，所以这个表达式有些混乱。总得来说，它匹配的是结构为”${若干字符}"。而这个结构对于HQL来说，是用于“变量替换”的。这个方法做的事情确实是剔除字符串中"${若干字符}"这个结构，并根据字符内容来获取变量替换上去。这里的问题我们就解决了。这里无论怎么进行替换，都是不会改变原本句子的结构的。
接下来一大段都是在为各种配置量输入信息、开启性能计算等等等等
直到这里

这个ASTNode就是我们的目标啦。parse这个方法产生了tree。对于ParseUtils.parse这个方法，我们要去着重看。
parse方法中间也有一层调用，最后是这里

这个注释证明我们的方向是对的。pd.parse是下一层，但是在这一层出现了一个问题

这个ANTLRNoCaseStringStream继承自ANTLRStringStream。而后者已经属于另一个项目了。那个项目叫Antrl，是一个语义分析器项目。它已经不属于hive了。

这其实很纠结，Antrl虽然负责了很重要的部分，但是它确实不属于hive。我需要找到一个合理的分析程度，视情况决定深挖或者利用远程访问debug来直接获取内容。我们下周继续。