前言
最近大部分時間都在擼 Python，其中也會涉及到將數據庫表轉換為 Python 中 ORM 框架的 Model，但我們並沒有找到一個合適的工具來做這個意義不大的”體力活“，所以每次新建表后大家都是根據自己的表結構手寫一遍 Model。
一兩張表還好，一旦 10 幾張表都要寫一遍時那痛苦只有自己知道；這時程序員的 slogan 再次印證：一切毫無意義的體力勞動終將被計算機取代。
intellij plugin
既然沒有現成的工具那就自己寫一個吧，演示效果如下：
考慮到我們主要是用 PyCharm 開發，正好 jetbrains 也提供了 SDK 用於開發插件，所以 UI 層面可以不用額外考慮了。
使用流程很簡單，只需要導入 DDL 語句就可以生成 Python 所需要的 Model 代碼。
例如導入以下 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
便會生成對應的 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
詞法解析
仔細對比源文件及目標代碼會很容易找出規律，無非就是解析出表名、字段、及字段的屬性（是否為主鍵、類型、長度），最后再轉換為 Python 所需要的模板即可。
在我動手之前我認為是非常簡單的，無非就是解析字符串，但實際上手后發現不是那么回事；主要是有以下幾個問題：
- 如何識別出表名稱？
- 同樣的如何識別出字段名稱，同時還得關聯上該字段的類型、長度、注釋。
- 如何識別出主鍵？
總結一句話，如何通過一系列規則識別出一段字符串中的關鍵信息，這同樣也是 MySQL Server 所做的事情。
在開始真正解析 DDL 之前，先來看下一段簡單的腳本如何解析：
x = 20
按照我們平時開發的經驗，這條語句分為以下幾部分：
x表示變量=表示賦值符號20表示賦值結果
所以我們對這段腳本的解析結果應當為：
VAR x
GE =
VAL 100
這個解析過程在編譯原理中稱為”詞法解析“，可能大家聽到編譯原理這幾個字就頭大（我也是）；對於剛才那段腳本我們可以編寫一個非常簡單的詞法解析器生成這樣的結果。
狀態遷移
再開始之前先捋一下思路，可以看到上文的結果中通過 VAR 表示變量、GE 表示賦值符號 ”=“、VAL 表示賦值結果，現在需要重點記住這三個狀態。
在依次讀取字符解析時，程序就是在這幾個狀態中來回切換，如下圖：
- 默認為初始狀態。
- 當字符為字母時進入
VAR狀態。 - 當字符為 ”=“ 符號時進入
GE狀態。
同理，當不滿足這幾個狀態時候又會回到初始從而再次確認新的狀態。
光看圖有點抽象，直接來看核心代碼：
public class Result{
public TokenType tokenType ;
public StringBuilder text = new StringBuilder();
}
首先定義了一個結果類，收集最終的解析結果；其中的 TokenType 就對應了圖中的三種狀態，簡單的用枚舉值來表示。
public enum TokenType {
INIT,
VAR,
GE,
VAL
}
首先對應到第一張圖：初始化狀態。
需要對當前解析的字符定義一個 TokenType：
和圖中描述的流程一致，判斷當前字符給定一個狀態即可。
接着對應到第二張圖：狀態之間的轉換。
會根據不同的狀態進入不同的 case，在不同的 case 中判斷是否應當跳轉到其他狀態（進入 INIT 狀態后會重新生成狀態）。
舉個例子： x = 20:
首選會進入 VAR 狀態，接着下一個字符為空格，自然在 38 行中重新進入初始狀態，導致再次確定下一個字符 = 進入 GE 狀態。
當腳本為 ab = 30:
第一個字符為 a 也是進入 VAR 狀態，第二個字符為 b，依然為字母，所以進入 36 行，狀態不會改變，同時將 b 這個字符追加進來；后續步驟就和上一個例子一致了。
多說無益，建議大家自己跑一下單測就會明白：
https://github.com/crossoverJie/sqlalchemy-transfer/blob/master/src/test/java/top/crossoverjie/plugin/core/lab/TestLexerTest.java
DDL 解析
簡單的解析完成后來看看 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
原理類似，首先還是要看出規律（也就是語法）：
- 表名是第一行語句，同時以
CREATE TABLE開頭。 - 每一個字段的信息（名稱、類型、長度、備注）都是以 "`" 符號開頭 "," 結尾。
- 主鍵是以 PRIMART 字符串開頭的字段，以
)結尾。
根據我們需要解析的數據種類，我這里定義了這個枚舉：
然后在初始化類型時進行判斷賦值：
由於需要解析的數據不少，所以這里的判斷條件自然也就多了。
遞歸解析
針對於 DDL 的語法規則，我們這里還有需要有特殊處理的地方；比如解析具體字段信息時如何關聯起來？
舉個例子：
`userName` varchar(20) DEFAULT NULL COMMENT '用戶名',
`password` varchar(100) DEFAULT NULL COMMENT '密碼',
這里我們解析出來的數據得有一個映射關系：
所以我們只能一個字段的全部信息解析完成並且關聯好之后才能解析下一個字段。
於是這里我采用了遞歸的方式進行解析（不一定是最好的，歡迎大家提出更優的方案）。
} else if (value == '`' && pStatus == Status.BASE_INIT) {
result.tokenType = DDLTokenType.FI;
result.text.append(value);
}
當當前字符為 ”`“ 符號時，將狀態置為 "FI"(FieldInfo)，同時當解析到為 "," 符號時便進入遞歸處理。
可以理解為將這一段字符串單獨提取出來處理：
`userName` varchar(20) DEFAULT NULL COMMENT '用戶名',
接着再將這段字符遞歸調用當前方法再次進行解析，這時便按照字段名稱、類型、長度、注釋的規則解析即可。
同時既然存在遞歸，還需要將子遞歸的數據關聯起來，所以我在返回結果中新增了一個 pid 的字段，這個也容易理解。
默認值為 0，一旦遞歸后便自增 +1，保證每次遞歸的數據都是唯一的。
用同樣的方法在解析主鍵時也是先將整個字符串提取出來:
PRIMARY KEY (`id`)
只不過是 "P" 打頭 ")" 結尾。
} else if (value == 'P' && pStatus == Status.BASE_INIT) {
result.tokenType = DDLTokenType.P_K;
result.text.append(value);
}
也是將整段字符串遞歸解析，再遞歸的過程中進行狀態切換 P_K ---> P_K_V 最終獲取到主鍵。
所以通過對剛才那段 DDL 解析得到的結果如下：
這樣每個字段也通過了 pid 進行了區分關聯。
所以現在只需要對這個詞法解析器進行封裝，便可以提供一個簡單的 API 來獲取表中的數據了。
總結
到此整個詞法解析器的全部內容都已經完成了，雖然實現的是一個小功能，但我自己花的時間可不少，其中光復習編譯原理就讓人頭疼。
但這還只是整個編譯語言知識點的冰山一角，后續還有語法、語義、中間、目標代碼等一系列內容，都是一個比一個難啃。
其實我相信大多數人和我想法一樣，這個東西太底層而且枯燥，真正從事這方面工作的也都是鳳毛麟角，所以花這時間干啥呢？
所以我也決定這個弄完后就棄坑啦。
哈哈，開個玩笑，或許有生之年自己也能實現一門編程語言，當老了和兒子吹牛時也能有點資本。
本文所有源碼及插件地址：
https://github.com/crossoverJie/sqlalchemy-transfer
大家看完記得點贊分享一鍵三連哦