Flask-Migrate的使用和常见"坑"的解决办法

1.Flask-Migrate的使用

flask-migrate相关配置：

from Application import app
from common.models.model import db
from flask_migrate import Migrate, MigrateCommand

migrate = Migrate(app, db, render_as_batch=True, compare_type=True, compare_server_default=True)
manager.add_command('db', MigrateCommand)
7 manager.add_command('runserver', Server(host='0.0.0.0'))

if __name__ == '__main__':
    manager.run()

flask-migrate相关的命令：

• python manage.py db init：初始化一个迁移脚本的环境，只需要执行一次。
• python manage.py db migrate：将模型生成迁移文件，只要模型更改了，就需要执行一遍这个命令。
• python manage.py db upgrade：将迁移文件真正的映射到数据库中。每次运行了migrate命令后，就记得要运行这个命令。

2. 常见"坑"的解决办法

第一坑：安装最新版本的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参数旁边还有一些其他的小参数，这次没有坑爹，比较给力，还是贴一下源码吧：

def configure(
        self,
        connection=None,
        url=None,
        dialect_name=None,
        dialect_opts=None,
        transactional_ddl=None,
        transaction_per_migration=False,
        output_buffer=None,
        starting_rev=None,
        tag=None,
        template_args=None,
        render_as_batch=False,
        target_metadata=None,
        include_name=None,
        include_object=None,
        include_schemas=False,
        process_revision_directives=None,
        compare_type=False,
        compare_server_default=False,
        render_item=None,
        literal_binds=False,
        upgrade_token="upgrades",
        downgrade_token="downgrades",
        alembic_module_prefix="op.",
        sqlalchemy_module_prefix="sa.",
        user_module_prefix=None,
        on_version_apply=None,
        **kw
    ):

这里有一个熟悉的面孔，没错！二号坑里的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)

 

除了以上4个比较常见的坑外，其实还有很多,不过我在学习过程中遇到暂时就只有这四个，后续如果遇到会补充。

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