flask-migrate相关配置：

第一坑：安装最新版本的flask-migrate插件

首先安装flask-migrate，如果直接pip install flask-migrate安装，默认是安装的是最新版本，这时候你会发现，最新版本和flask的版本会有冲突，导入MigrateCommand时报错。

解决办法：

指定版本安装 ，经过测试：Flask==1.1.2  flask-migrate==2.7.0不会出现问题。

    安装完flask-migrate后，为了更好的使用它，我们还得安装另一个很实用的插件flask-script,这是一个项目管理类的插件，可以自定义命令去管理我们的项目。同样的该插件的最新版本，也会和高版本的flask产生冲突，经过测试Flask==1.1.2不会出现问题。

所以说，如果要使用以上两个插件，Flask版本不能太高，否则会出现兼容问题。

第二坑：当使用sqlite时的alter

这次坑的是sqlite，主要是sqlite自己太坑。它不支持drop列，不支持完整的数据库alter语句功能等等。当使用sqlite做migrate和upgrade以及downgrade时，模型有字段的减少或者约束的减少，会报错：

sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) near "DROP": syntax error [SQL: ALTER TABLE account DROP COLUMN name]

解决方法：

初始化Migrate对象时可以设置其提交类型为批处理 migrate = Migrate(db=db, render_as_batch=True)

    以批处理的方式做表结构修改sqlite是支持的，但是批处理本身有安全性的问题。批处理提升了效率，但是丧失了原子性，其中某些sql语句出错我们并不能直接感知到。所以尽量对migrate生成的脚本进行人工检查吧，不怕一万就怕万一。

第三坑：字段长度等属性的修改

FlaskMigrate默认对字段属性的变动是不做检查的。所以当发现256长的A字段的不足以支撑功能，我们需要把它变成1000，修改代码后做migrate会发现提示No changes in schema detected.

解决方法：

上面提到的alembic的源码的EnvironmentContext类内的configure方法里有个sqlalchemy_module_prefix参数旁边还有一些其他的小参数，这次没有坑爹，比较给力，还是贴一下源码吧：

这里有一个熟悉的面孔，没错！二号坑里的render_as_batch参数也在这里。同时，还有一个叫做compare_type的参数，默认是False，该参数用于标注是否比较字段属性变化。所以，同二号坑，在初始化Migrate对象的时候加入该参数，如下：

Migrate(db=db, render_as_batch=True, compare_type=True)

第四坑：default默认约束的生成

     sqlalchemy的默认值设置有两种方式，第一种是直接的在Column中设置default，这种方式并不在数据库生成默认值约束，是依靠sqlalchemy自身的功能在生成数据的时候生成默认值。另一种是server_default，这种方式是直接在数据库内生成默认值约束。使用较为麻烦，因为server_default参数只接受str或者unicode这种类型，比如Integer字段也需要设置为字符串，时间戳则需要自己转化，较为麻烦。所以，想要在数据迁移时生成数据库的约束，需要使用server_default而不是default。此外，在三号坑内的源码里，也能看见一个熟脸，就是compare_server_default，默认值是False。

解决方法：

1.保证model内所有有默认值的字段的default以server_default形式设置。 

2.初始化Migrate对象时做配置：migrate = Migrate(db=db, render_as_batch=True, compare_type=True, compare_server_default=True)

第五坑:  flask命令行更新数据库 Error: Target database is not up to date

解决问题

> python manage.py db stamp heads

再次查看magration的heads和current版本发现保持一致！

参考博客：https://blog.csdn.net/c_s_y/article/details/90769675