前言

昨天讲完了 manage.py 跟我们新加入的几个自订指令，今天我们还是离不开 manage.py，而且昨天引入但是没有用到的 db 也要登场了。

今天要登场的是 database migration，它是用来更新资料库结构的，可以想成资料库的版本控制。

初始化

我们要先在 manage.py 里面加入以下几行。

from flask_migrate import Migrate
migrate = Migrate(app, db, render_as_batch=True)

这样就完成了，现在我们可以使用 flask 指令来处理资料库的变化了。

flask db

在开始之前，我们要先把 data.db (之前生出来的资料库档案) 删掉，然後重新开始。

最一开始，我们需要先初始化，要使用 flask db init，他应该会跑一下下，然後生出一个叫做 migration/ 的目录，但现在里面还没甚麽内容。

接着我们要使用 flask db migrate -m "description" 来建立一个版本，-m 後面要加上这个版本的说明之类的，有点像 git 的感觉。而这个版本的来源是我们的 models.py，而不是现在资料库的样子。这样一来，他就会生出一个新的版本，放在 migration/versions/ 里面，他会有一个独特的编号，像 git 每一个 commit 都有编号一样。

但建好这个版本之後，我们资料库还没有跟上，必须要使用 flask db upgrade 来把它升级到新版本，理论上第一个版本应该是建立好三个 table。这时候打开资料库，应该会看到里面已经有建好的 table，然後还有外加一个 Flask-Migrate 在用的 table。

我们现在可以尝试在这个资料库里面加入一些资料，加入文章跟留言会被昨天提到的外键卡到，所以我们加入一个新的使用者来当作范例，看等等建立新版并且升级之後这笔资料会发生甚麽事。

接着我们到 models.py 稍微调整一下资料库结构，我们尝试加入一个 test = db.Column(db.String) 在 Users 里面。现在我们的 models.py 已经更动了，所以我们可以建立新的版本，再次使用 flask db migrate，这时候应该可以看到他会说侦测到有加入的 column，然後一个新版本就建好了。在升级之前我们可以看看一些小东西。flask db current 会让你知道你现在在哪个版本，而 flask db heads 则会让你知道现在的最新版本。

看完之後应该就可以看到 current 跟 heads 是不一样的，所以这时候就可以再来 flask db upgrade，让他升级上去。最後我们打开资料库，应该会看到 users 这个 table 已经更新了，加入了一个新的栏位，但同时旧的资料也没有被删除。

当然，这是一个测试用的版本，我们不会留在这个版本做事，所以我们要用 flask db downgrade 来退回前一个版本。在最一开始的初始化中，我们加入了一个 render_as_batch 的参数，会加入他是因为我们开发中先使用 sqlite，但他遇到删除栏位的时候会爆炸，加上这个参数之後他就会换个方式，会变成把本来的资料库砍掉然後重建，再把旧的资料复制过去新的，所以就可以避免掉 sqlite 不让我们删除的问题。

References

实作 Flask-Migrate更新资料库
DAY26-搞懂Flask-Migrate
Flask实作 ext 06 Flask-Migrate
Why Flask-migrate cannot upgrade when drop column
Sqlite lack of ALTER support, Alembic migration failing because of this. Solutions?