风爻的开发日常-打造生产级的Flask Migrate操作

风爻的开发日常

打造生产级的Flask Migrate操作

在很久很久以前

在涉及到关系型数据库开发时

我们每次在线上操作数据库

都需要找一个叫DBA的狠角色

时光荏苒，就这样过了一年又一年

一群不堪压迫，集颜值、智商、动手能力于一身的程序员们发现，明明我们手里有操纵DB的能力，为什么要把命运交给别人主宰呢？

这群程序员做了一个伟大的决定！

让数据库的数据结构也能够通过版本追踪

这种操作，就被称为

Database Migrate

显然，这么风骚的操作引起了DBA的不满

（一大波萌新DBA岗位或将面临淘汰）

其实，对于到底是先有表结构还是先有模型的问题，风爻的答案是

在风爻看来，这样的争论毫无意义。

不同的团队，开发风格和协作模式不一样。

如果先存在表结构，显然应该先有表，（好像是废话？）这种情况是不适用于Migrate操作来管理DB的，但是（麻麻说，但是前面都是废话）对等的，开发人员也不应该承担维护DB的责任。

所以如果你的团队或项目还没有实现Migrate，你可以理直气壮的要求他们提供像Migrate一样的收益。

其实，近十年来，随着MVC、敏捷开发、DevOPS等等设计、开发模式从出现、探讨到成熟。

Migrate已经是一种不争的维护关系型数据库表结构的手段之一（虽然很想说没有之一，嘛~ 做人要谦虚）。

然而很不幸的是，虽然Flask有比较稳定的flask-migrate来支持这一功能。

但是官方文档给出的做法……

这也是风爻一直认为Flask生态最大的问题，极其简单，学习迅速。

但是用好Flask，做到生产级可用，真的不简单。

他不像Django用约束换取自由，Flask本身可以认为是完全自由的。

让风爻又想起了社区的金句：

Pirates use Flask,the navy uses Django

风爻认为一个生产级的Migrate的指标有：

基础指标：

- 正确识别表结构变动并支持Migrate

- 支持回滚操作（可以是有条件限制的）

- 支持多个模块的Migrate

进阶指标：

- 自动触发Migrate操作

- 新项目可以只复用表结构而无需复用Migrations

很不幸的是，flask-migrate除了基础指标的1和2之外，均不能达成……

所以，是时候从入门到放弃了吗？

当然不！风爻要告诉你的是：这世上不存在开源且完全符合自身需求的程序。如果有，在编程这条路上，你离被淘汰不远了。

Step1. 实现跨模块

分析：

Flask框架风格追求Micro。所以每个App风格都是尽可能少的引用，于是每个App中的Model只会包含数据库中的一部分而不是全部。

这其实和Migrate的思路产生了冲突。因为Migrate的目标是掌控整个数据库。

如果我们有办法让Migrate识别出所有的Model，那问题不是就解决了？

核心代码：

完整版传送门：

https://github.com/wangwenpei/fantasy/blob/master/fantasy/cli.py#L71

Step2. 自动触发Migrate

分析：

如果你对Migrate的概念比较熟悉。你就会意识到，Migrate操作始终是在当前版本代码载入生效之前执行的。

常见的思路是，我们通常会把这种操作构建到持续部署（continuous deployment）系统中。

而基于Flask自由的灵魂，我们还可以构造出更加灵活简单的方式，只要我们保证在代码生效前执行就可以了。

核心代码：

完整版传送门：

https://github.com/wangwenpei/fantasy/blob/master/fantasy/__init__.py#L63

Step3. 多项目无冲突复用表结构

使用场景：

随着公司和项目的成长，举例：人事的变动，已有的项目A负责人开始接手新项目B。老项目A和项目B之间是完全独立的。而有一部分数据库表结构，希望只共用结构，而不共用数据。比如：消息发送记录表（table1)。

一个粗暴的办法，我们当然可以直接施展复制粘贴大法，从此分道扬镳。在风爻看来，这种策略实在低级，牺牲了太多特性。

风爻认为一个好的策略是这样的：

- 一方负责维护，其他方仅引用使用。

这样一旦有商议通过的更新，所有人都会同步更新，项目组之间无需独立维护。

- 新项目只依赖需要的数据结构，创建全新的migrations文件。

项目A的依赖关系没有任何变动，项目B的依赖关系为全新，互不影响。

完整Demo：

https://github.com/wangwenpei/shining-flask/tree/master/aivptr

以上就是本次的阅读5分钟，Coding两小时的所有内容啦。别光看图，记得看代码，代码比图好看多了，我认真的。

Demo Code:aivptr

第二期，连自己没想到居然没有跳票如约完成了，仔细想想，这是陪产假的功劳啊，碎片化的时间干这个貌似正合适。

感谢读者们的支持，坦白说，被将近300号人盯着更新，真的是有点压力，我们射基师妹纸都快吓哭了要知道，现在运营一个公众号，平均水平即使砸些小钱，一周转化能有100粉真实关注都要偷着乐了，何况自己之前只是做了个简单的开篇，0元推广，还就只推了一天，简直是白嫖水准。客观说我认为第一篇只能算序章，V站的一位同学形容的很到位：“只有钩子没有饵料”。其实我们之前也有考虑过要不要先摘一章有干货的出来吸粉这样的方案，经过多次讨论，最终我们还是选择循序渐进的正叙模式，技术文章还是需要由浅入深，不能偷懒。在“没有饵料”的情况下还能关注，十二分感谢大家的包容。按期奉上食材，请笑纳。

下期预告

风爻的开发日常——

没有测试用例的项目都是耍流氓

预计7月中旬上线，依然无责任跳票（新入职某厂，事情真的超多）

风爻哥哥

阅读5分钟，Coding两小时