前言

最近大部分時(shí)間都在擼Python，其中也會涉及到將數(shù)據(jù)庫表轉(zhuǎn)換為Python中ORM框架的Model，但我們并沒有找到一個(gè)合適的工具來做這個(gè)意義不大的”體力活“，所以每次新建表后大家都是根據(jù)自己的表結(jié)構(gòu)手寫一遍Model。

一兩張表還好，一旦 10 幾張表都要寫一遍時(shí)那痛苦只有自己知道；這時(shí)程序員的 slogan 再次印證：一切毫無意義的體力勞動終將被計(jì)算機(jī)取代。

intellij plugin

既然沒有現(xiàn)成的工具那就自己寫一個(gè)吧，演示效果如下：

考慮到我們主要是用PyCharm開發(fā)，正好jetbrains也提供了SDK用于開發(fā)插件，所以UI層面可以不用額外考慮了。

使用流程很簡單，只需要導(dǎo)入DDL語句就可以生成Python所需要的Model代碼。

例如導(dǎo)入以下 DDL：

CREATE TABLE `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `userName` varchar(20) DEFAULT NULL COMMENT '用戶名',
  `password` varchar(100) DEFAULT NULL COMMENT '密碼',
  `roleId` int(11) DEFAULT NULL COMMENT '角色I(xiàn)D',
  PRIMARY KEY (`id`),  
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8

便會生成對應(yīng)的 Python 代碼：

class User(db.Model):
    __tablename__ = 'user'
    id = db.Column(db.Integer, primary_key=True, autoincrement=True)
    userName = db.Column(db.String)  # 用戶名
    password = db.Column(db.String)  # 密碼
    roleId = db.Column(db.Integer)  # 角色I(xiàn)D

詞法解析

仔細(xì)對比源文件及目標(biāo)代碼會很容易找出規(guī)律，無非就是解析出表名、字段、及字段的屬性（是否為主鍵、類型、長度），最后再轉(zhuǎn)換為Python所需要的模板即可。

在我動手之前我認(rèn)為是非常簡單的，無非就是解析字符串，但實(shí)際上手后發(fā)現(xiàn)不是那么回事；主要是有以下幾個(gè)問題：

• 如何識別出表名稱？
• 同樣的如何識別出字段名稱，同時(shí)還得關(guān)聯(lián)上該字段的類型、長度、注釋。
• 如何識別出主鍵？

總結(jié)一句話，如何通過一系列規(guī)則識別出一段字符串中的關(guān)鍵信息，這同樣也是 MySQL Server 所做的事情。

在開始真正解析 DDL 之前，先來看下一段簡單的腳本如何解析：

x = 20

按照我們平時(shí)開發(fā)的經(jīng)驗(yàn)，這條語句分為以下幾部分：

• x表示變量
• =表示賦值符號
• 20表示賦值結(jié)果

所以我們對這段腳本的解析結(jié)果應(yīng)當(dāng)為：

VAR x

GE =

VAL 100

這個(gè)解析過程在編譯原理中稱為”詞法解析“，可能大家聽到編譯原理這幾個(gè)字就頭大（我也是）；對于剛才那段腳本我們可以編寫一個(gè)非常簡單的詞法解析器生成這樣的結(jié)果。

狀態(tài)遷移

再開始之前先捋一下思路，可以看到上文的結(jié)果中通過VAR表示變量、GE表示賦值符號 ”=“、VAL表示賦值結(jié)果，現(xiàn)在需要重點(diǎn)記住這三個(gè)狀態(tài)。

在依次讀取字符解析時(shí)，程序就是在這幾個(gè)狀態(tài)中來回切換，如下圖：

• 默認(rèn)為初始狀態(tài)。
• 當(dāng)字符為字母時(shí)進(jìn)入VAR狀態(tài)。
• 當(dāng)字符為 ”=“ 符號時(shí)進(jìn)入GE狀態(tài)。

同理，當(dāng)不滿足這幾個(gè)狀態(tài)時(shí)候又會回到初始從而再次確認(rèn)新的狀態(tài)。

光看圖有點(diǎn)抽象，直接來看核心代碼：

public class Result{
    public TokenType tokenType ;
    public StringBuilder text = new StringBuilder();
}

首先定義了一個(gè)結(jié)果類，收集最終的解析結(jié)果；其中的TokenType就對應(yīng)了圖中的三種狀態(tài)，簡單的用枚舉值來表示。

public enum TokenType {
    INIT,
    VAR,
    GE,
    VAL
}

首先對應(yīng)到第一張圖：初始化狀態(tài)。

需要對當(dāng)前解析的字符定義一個(gè)TokenType：

和圖中描述的流程一致，判斷當(dāng)前字符給定一個(gè)狀態(tài)即可。

接著對應(yīng)到第二張圖：狀態(tài)之間的轉(zhuǎn)換。

會根據(jù)不同的狀態(tài)進(jìn)入不同的case，在不同的case中判斷是否應(yīng)當(dāng)跳轉(zhuǎn)到其他狀態(tài)（進(jìn)入INIT狀態(tài)后會重新生成狀態(tài)）。

舉個(gè)例子：x = 20:

首選會進(jìn)入VAR狀態(tài)，接著下一個(gè)字符為空格，自然在 38 行中重新進(jìn)入初始狀態(tài)，導(dǎo)致再次確定下一個(gè)字符=進(jìn)入GE狀態(tài)。

當(dāng)腳本為ab = 30:
第一個(gè)字符為 a 也是進(jìn)入VAR狀態(tài)，第二個(gè)字符為 b，依然為字母，所以進(jìn)入 36 行，狀態(tài)不會改變，同時(shí)將 b 這個(gè)字符追加進(jìn)來；后續(xù)步驟就和上一個(gè)例子一致了。

多說無益，建議大家自己跑一下單測就會明白：

https://github.com/crossoverJie/sqlalchemy-transfer/blob/master/src/test/java/top/crossoverjie/plugin/core/lab/TestLexerTest.java

DDL 解析

簡單的解析完成后來看看DDL這樣的腳本應(yīng)當(dāng)如何解析：

CREATE TABLE `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `userName` varchar(20) DEFAULT NULL COMMENT '用戶名',
  `password` varchar(100) DEFAULT NULL COMMENT '密碼',
  `roleId` int(11) DEFAULT NULL COMMENT '角色I(xiàn)D',
  PRIMARY KEY (`id`),  
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8

原理類似，首先還是要看出規(guī)律（也就是語法）：

• 表名是第一行語句，同時(shí)以CREATE TABLE開頭。
• 每一個(gè)字段的信息（名稱、類型、長度、備注）都是以 “`” 符號開頭 “,” 結(jié)尾。
• 主鍵是以 PRIMART 字符串開頭的字段，以)結(jié)尾。

根據(jù)我們需要解析的數(shù)據(jù)種類，我這里定義了這個(gè)枚舉：

然后在初始化類型時(shí)進(jìn)行判斷賦值：

由于需要解析的數(shù)據(jù)不少，所以這里的判斷條件自然也就多了。

遞歸解析

針對于DDL的語法規(guī)則，我們這里還有需要有特殊處理的地方；比如解析具體字段信息時(shí)如何關(guān)聯(lián)起來？

舉個(gè)例子：

`userName` varchar(20) DEFAULT NULL COMMENT '用戶名',
`password` varchar(100) DEFAULT NULL COMMENT '密碼',

這里我們解析出來的數(shù)據(jù)得有一個(gè)映射關(guān)系：

所以我們只能一個(gè)字段的全部信息解析完成并且關(guān)聯(lián)好之后才能解析下一個(gè)字段。

于是這里我采用了遞歸的方式進(jìn)行解析（不一定是最好的，歡迎大家提出更優(yōu)的方案）。

} else if (value == '`' && pStatus == Status.BASE_INIT) {
    result.tokenType = DDLTokenType.FI;
    result.text.append(value);
}

當(dāng)當(dāng)前字符為 ”`“ 符號時(shí)，將狀態(tài)置為 “FI”(FieldInfo)，同時(shí)當(dāng)解析到為 “,” 符號時(shí)便進(jìn)入遞歸處理。

可以理解為將這一段字符串單獨(dú)提取出來處理：

`userName` varchar(20) DEFAULT NULL COMMENT '用戶名',

接著再將這段字符遞歸調(diào)用當(dāng)前方法再次進(jìn)行解析，這時(shí)便按照字段名稱、類型、長度、注釋的規(guī)則解析即可。

同時(shí)既然存在遞歸，還需要將子遞歸的數(shù)據(jù)關(guān)聯(lián)起來，所以我在返回結(jié)果中新增了一個(gè)pid的字段，這個(gè)也容易理解。

默認(rèn)值為 0，一旦遞歸后便自增 +1，保證每次遞歸的數(shù)據(jù)都是唯一的。

用同樣的方法在解析主鍵時(shí)也是先將整個(gè)字符串提取出來:

PRIMARY KEY (`id`)

只不過是 “P” 打頭 “)” 結(jié)尾。

} else if (value == 'P' && pStatus == Status.BASE_INIT) {
    result.tokenType = DDLTokenType.P_K;
    result.text.append(value);
}

也是將整段字符串遞歸解析，再遞歸的過程中進(jìn)行狀態(tài)切換P_K ---> P_K_V最終獲取到主鍵。

所以通過對剛才那段DDL解析得到的結(jié)果如下：

這樣每個(gè)字段也通過了pid進(jìn)行了區(qū)分關(guān)聯(lián)。

所以現(xiàn)在只需要對這個(gè)詞法解析器進(jìn)行封裝，便可以提供一個(gè)簡單的API來獲取表中的數(shù)據(jù)了。

總結(jié)

到此整個(gè)詞法解析器的全部內(nèi)容都已經(jīng)完成了，雖然實(shí)現(xiàn)的是一個(gè)小功能，但我自己花的時(shí)間可不少，其中光復(fù)習(xí)編譯原理就讓人頭疼。

但這還只是整個(gè)編譯語言知識點(diǎn)的冰山一角，后續(xù)還有語法、語義、中間、目標(biāo)代碼等一系列內(nèi)容，都是一個(gè)比一個(gè)難啃。

本文所有源碼及插件地址：

https://github.com/crossoverJie/sqlalchemy-transfer

以上就是java詞法分析器DDL遞歸應(yīng)用詳解的詳細(xì)內(nèi)容，更多關(guān)于java DDL遞歸詞法分析器的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論