前言
最近大部分時間都在擼
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 xGE =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
大家看完記得點贊分享一鍵三連哦
