前言

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

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

intellij plugin

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

考慮到我們主要是用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 '角色ID',
  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)  # 角色ID

詞法解析

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

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

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

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

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

x = 20

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

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

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

VAR x

GE =

VAL 100

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

狀態(tài)遷移

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

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

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

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

光看圖有點抽象，直接來看核心代碼：

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

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

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

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

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

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

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

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

舉個例子：x = 20:

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

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

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

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 '角色ID',
  PRIMARY KEY (`id`),  
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8

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

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

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

然后在初始化類型時進行判斷賦值：

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

遞歸解析

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

舉個例子：

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

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

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

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

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

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

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

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

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

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

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

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

PRIMARY KEY (`id`)

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

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

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

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

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

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

總結(jié)

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

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

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

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

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

最新評論