最近大部分时间都在撸 Python
,其中也会涉及到将数据库表转换为 Python
中 ORM
框架的 Model
,但咱们并无找到一个合适的工具来作这个意义不大的”体力活“,因此每次新建表后你们都是根据本身的表结构手写一遍 Model
。java
一两张表还好,一旦 10 几张表都要写一遍时那痛苦只有本身知道;这时程序员的 slogan 再次印证:一切毫无心义的体力劳动终将被计算机取代。python
既然没有现成的工具那就本身写一个吧,演示效果以下:
git
考虑到咱们主要是用 PyCharm
开发,正好 jetbrains
也提供了 SDK
用于开发插件,因此 UI
层面能够不用额外考虑了。程序员
使用流程很简单,只须要导入 DDL
语句就能够生成 Python
所须要的 Model
代码。github
例如导入如下 DDL:sql
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
所须要的模板便可。编程
在我动手以前我认为是很是简单的,无非就是解析字符串,但实际上手后发现不是那么回事;主要是有如下几个问题:app
总结一句话,如何经过一系列规则识别出一段字符串中的关键信息,这一样也是 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
这样的脚本应当如何解析:
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
开头。)
结尾。根据咱们须要解析的数据种类,我这里定义了这个枚举:
而后在初始化类型时进行判断赋值:
因为须要解析的数据很多,因此这里的判断条件天然也就多了。
针对于 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
你们看完记得点赞分享一键三连哦