创建和部署flask中有关migrate可能遇到的问题

这篇文章是jtr_109发在cocode中的一篇帖子，感觉看后挺有收获并且以后可能会用到所以转过来了，他的git是https://github.com/jtr109我自己在创建完迁移脚本后（可参考我另一篇关于flask-migrate的文章）执行pythonmanage.py db upgrade进行更新时，发现只出现(base) C:\Users\kai\PycharmProjects

kkevinyang

16826人浏览 · 2016-08-11 16:23:08

kkevinyang · 2016-08-11 16:23:08 发布

这篇文章是jtr_109发在cocode中的一篇帖子，感觉看后挺有收获并且以后可能会用到所以转过来了，他的git是https://github.com/jtr109

我自己在创建完迁移脚本后（可参考我另一篇关于flask-migrate的文章）执行python manage.py db upgrade进行更新时，发现只出现

(base) C:\Users\kai\PycharmProjects\practice\myflasky>python manage.py db upgrade
INFO  [alembic.runtime.migration] Context impl SQLiteImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.

的字样，并没有真正创建成功，而输入python manage.py db migrate的话，又会出现

(base) C:\Users\kai\PycharmProjects\practice\myflasky>python manage.py migrate
usage: manage.py [-?] {runserver,shell,db,test} ...
manage.py: error: invalid choice: 'migrate' (choose from 'runserver', 'shell', 'db', 'test')

的提醒，后来参考jtr_109下面的帖子的经验，我意识到之后每次更新数据库应该都是要先migrate再upgrade的，而且要给更新的脚本署名，就类似于先更新脚本，flask才会根据新的脚本数据再去更新数据库相应模型。所以我就尝试输入

python manage.py db migrate -m "add user profile"

显示的成功了.

注：之后还需要输入python manage.py db upgrade完成迁移

下面是jtr_109的原文：

影响 migrate 的是数据库的结构。
- 比方说你的 User 类中添加了一个 Column - nickname ，那么在保存 Model 之后建议执行 python manage.py db migrate -m "add nickname；
- 而给 table 加入了新的方法，例如 def change_nick_name() ，是不需要 migrate 的。如果 migrate，结果也是 No change；
- 这一点可以留意一下，比较保险的办法是觉得有必要的时候就尝试一下 migrate，反正 No changes 对你的迁移也没有影响。
在创建本地数据库的时候，不要在 py shell 环境下执行 db.create_all()
- 请使用python manage.py db init, python manage.py db upgrade 来创建本地数据库。
- 通常我会模仿书本上在上面两条指令之间再做一次migrate，但经验告诉我，结果好像都是No changes，毕竟，我init之后没有做过调整啊。
- init指令会根据Model.py中的结构创建迁移文件夹migrations，而upgrade会根据migrations下的内容，通过config.py在找到正确的位置，并创建SQL，并在SQL中创建一个名为versions的table来存放和迁移文件夹中相同的版本号。（重要）
- 在开始的尝试中，特别是往heroku上部署的过程中，经常会遇到许多数据库的坑，如果实在走投无路，又确定是数据库迁移问题，并且无法优雅地解决。你需要做的就是以下几步：
  (1). 休息一下，我知道你很累了
  (2). 执行python manage.py db shell，在py shell环境下执行drop_all()；或者直接删了你的原有数据库。
  (3). 按照本段前面的提示重新创建本地SQL
  (4). drop_all()或者删除并重新指定远端数据库
  (5). 执行heroku run python manage.py db deploy（假设你部署在heroku上，并已经完成了deploy的定义）
  (6). 现在你的远端和本地数据库的版本是相同的了。
如果本地使用sqlite作为数据库，千万不要从model.py中删除column！
- 这一点非常重要，因为根据我查到到资料显示，sqlite是没有“删除行”这一个选项的。如果你删除了某个column，这一操作能被migrate正确记录，但是在你upgrade的时候就会报错。然后想要还原migrate版本？抱歉，我不会……（欢迎朋友们指导一下，谢谢！）
部署到远端时，请确认你又versions文件夹
- 我不确定init会不会有，在执行migrate指令时，会更新versions文件夹
- 如果没有versions文件夹，远端部署的时候也会报错，请务必留意。
理解每个迁移指令的含义
- init的作用是初始化迁移，创建migration文件夹
- migrate的作用是根据model.py中的变化更新迁移，该指令会在migration/versions/文件夹中新增一个版本文件，文件名为版本号。打开能够看到对应model.py文件，修改前后新迁移版本发生的变化。
- update会将迁移中最新版本的结构应用到数据库中（例如添加新增的列），并更新自动创建的version表中的版本号。该版本号与migration/versions/文件夹中对应。任何情况下，这两个版本号不对应都会导致出错。