【问题标题】:flask migrate upgrade not working after drop table删除表后烧瓶迁移升级不起作用
【发布时间】:2017-03-07 22:32:29
【问题描述】:

我正在使用 SqlAlchemy 和 Flask-migrate 进行数据库迁移。我已经成功地使用以下方法初始化了数据库并升级了一次:

python manage.py db init
python manage.py db migrate # 创建迁移脚本,faefc6a6c7ae,如下:

"""empty message

Revision ID: faefc6a6c7ae
Revises: None
Create Date: 2016-10-25 22:09:25.615569

"""

# revision identifiers, used by Alembic.
revision = 'faefc6a6c7ae'
down_revision = None

from alembic import op
import sqlalchemy as sa


def upgrade():
    ### commands auto generated by Alembic - please adjust! ###
    op.create_table('users',
    sa.Column('id', sa.Integer(), nullable=False),
    sa.Column('name', sa.String(length=100), nullable=False),
    sa.Column('email', sa.String(length=100), nullable=False),
    sa.Column('password', sa.String(length=100), nullable=False),
    sa.PrimaryKeyConstraint('id')
    )
    op.create_table('posts',
    sa.Column('id', sa.Integer(), nullable=False),
    sa.Column('title', sa.String(length=50), nullable=False),
    sa.Column('description', sa.String(length=50), nullable=False),
    sa.Column('author_id', sa.Integer(), nullable=True),
    sa.ForeignKeyConstraint(['author_id'], ['users.id'], ),
    sa.PrimaryKeyConstraint('id')
    )
    ### end Alembic commands ###


def downgrade():
    ### commands auto generated by Alembic - please adjust! ###
    op.drop_table('posts')
    op.drop_table('users')
    ### end Alembic commands ###

然后

python manage.py db upgrade # 实际执行迁移并在 db 中创建 'users' 和 'posts' 表。

现在我运行我的 test.py,其中包含以下代码行(除了其他代码):

from flask_testing import TestCase
class BaseTestCase(TestCase):
    def create_app(self):
        app.config.from_object('config.TestConfig')
        return app

    def setUp(self):
        db.create_all()
        db.session.add(BlogPost("Test post", "This is a test. Only a test."))
        db.session.add(User("admin", "ad@min.com", "admin"))
        db.session.commit()

    def tearDown(self):
        db.session.remove()
        db.drop_all()

现在,在 test.py 完成运行后,tearDown() 会删除数据库中的所有表。

在此之后,现在当我运行时

python manage.py 数据库升级

它在控制台上给了我以下消息:

INFO [alembic.runtime.migration] 上下文实现 MySQLImpl.
INFO [alembic.runtime.migration] 将采用非事务性 DDL。

但根本没有真正创建相应的表。我有一个解决方法。所以如果我做一个:

python manage.py db migrate # 创建一个新的迁移脚本(与之前的没有太大区别),如下所示:

"""empty message

Revision ID: 848398c80589
Revises: faefc6a6c7ae
Create Date: 2016-10-26 00:06:26.468354

"""

# revision identifiers, used by Alembic.
revision = '848398c80589'
down_revision = 'faefc6a6c7ae'

from alembic import op
import sqlalchemy as sa


def upgrade():
    ### commands auto generated by Alembic - please adjust! ###
    op.create_table('users',
    sa.Column('id', sa.Integer(), nullable=False),
    sa.Column('name', sa.String(length=100), nullable=False),
    sa.Column('email', sa.String(length=100), nullable=False),
    sa.Column('password', sa.String(length=100), nullable=False),
    sa.PrimaryKeyConstraint('id')
    )
    op.create_table('posts',
    sa.Column('id', sa.Integer(), nullable=False),
    sa.Column('title', sa.String(length=50), nullable=False),
    sa.Column('description', sa.String(length=50), nullable=False),
    sa.Column('author_id', sa.Integer(), nullable=True),
    sa.ForeignKeyConstraint(['author_id'], ['users.id'], ),
    sa.PrimaryKeyConstraint('id')
    )
    ### end Alembic commands ###


def downgrade():
    ### commands auto generated by Alembic - please adjust! ###
    op.drop_table('posts')
    op.drop_table('users')
    ### end Alembic commands ###

如果我这样做了

python manage.py 数据库升级

再次创建表。

现在我想了解为什么没有创建表格

python manage.py 数据库升级

本身是第一次运行? db migrate 创建的 2 个迁移脚本并没有太大的不同,或者是吗?那么,为什么升级本身第一次不能工作(当升级实际上有创建表的代码时),为什么当再次生成新脚本时它会完美工作(升级方法本身根本没有改变,因为与之前的迁移脚本相比?

【问题讨论】:

    标签: flask sqlalchemy flask-sqlalchemy alembic flask-migrate


    【解决方案1】:

    drop_tables 只删除它知道的表。 Alembic 添加了自己的表alembic_version,以跟踪数据库正在进行的迁移。由于 drop_tables 没有删除该表,因此 Alembic 仍然可以看到它在运行升级后设置的值。改为运行downgrade 命令返回空初始状态。

    from flask_migrate import downgrade
    
    downgrade(revision='base')
    

    但是,您不应该仅仅为了运行测试而降级,您应该使用单独的数据库,这样您就不会弄乱开发或生产数据。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2020-09-30
      • 2017-07-24
      • 1970-01-01
      • 2015-01-10
      • 2023-04-04
      • 1970-01-01
      • 2019-01-26
      • 1970-01-01
      相关资源
      最近更新 更多