值得使用sqlalchemy-migrate吗? [英] Is it worth using sqlalchemy-migrate ?

问题描述

我有一个使用sqlalchemy的Web应用程序(在Pylons中).我需要有效地更改架构，以便至少每天(可能更多)更改生产版本，而又不会丢失数据.

I have a web application using sqlalchemy (within Pylons). I need to effiently change the schema to be able to change the production version at least on a daily basis, maybe more, without losing the data.

我在周末用sqlalchemy-migrate玩了一点，我会说这给了我不好的印象.首先，我认为这对两个数据库引擎之间的迁移无济于事；仅使用sqlalchemy即可完成此操作. 其次，文档似乎不是最新的.我不得不更改一些命令行选项，例如在每个命令中提供存储库路径，这可能是迁移的错误.

I have played a little bit with sqlalchemy-migrate over the week-end and I would say that it gave me a bad impression. First I think it cannot help with migration between two databases engines; that's something that could probably be done with sqlalchemy alone. Second the docs do not seem up to date. I had to change some command-line options, like giving the repository path at each command, this could be a bug of migrate.

但是最糟糕的是"manage.py 测试"命令.不仅它实际上修改了数据库(这一点在文档中已明确指出，所以我不能怪罪迁移)，而且我的第一个迁移脚本只是进行了简单的愚蠢的模式迁移，而将升级后降级的数据库保留了下来. 与原始模式不同的.但是"manage.py测试"只是回答了类似的问题

But the worst thing it the "manage.py test" command. Not only it actually modifies the database (this point is clearly indicated in the documentation so I can't blame migrate) but my first migration script just made plain stupid schema migration, leaving the upgraded-downgraded db with a different schema than the original. But the "manage.py test" just answered something like

 success !

也就是说，它甚至没有检查架构是否保持一致状态. 那么值得使用迁移吗?与与良好实践相关的自己动手"方法相比，有什么优势吗?

That is, it did not even check if the schema was left in a coherent state. So is it worth using migrate? Is there any advantage compared to the Do It Yourself method associated with good practices as proposed by S.Lott ? Are there alternatives to sqlalchemy-migrate actually simplifying the migration process or am I just trying to use migrate with a bad a priori (then please show me why is't clearly superior to creating CSV columns as proposed in the link above)?

非常感谢！

推荐答案

使用Alembic代替:

Use Alembic instead:

http://pypi.python.org/pypi/alembic

感谢评论，已添加一些理由进行了编辑-

Thanks for comments, edited to add some reasoning --

它是由SQLAlchemy的作者开发的，它是全新的，受到了很好的支持.我对sqlalchemy-migrate的了解不足，无法给出很好的比较.但是我快速浏览了简洁明了的Alembic文档，然后在很短的时间内就完成了自己的自动生成的迁移.

It's developed by the author of SQLAlchemy, and it's brand new and well supported. I don't know enough about sqlalchemy-migrate to give a good comparison. But I took a quick read through the clear and concise Alembic docs, then got my own autogenerated migration working in a very short time.

自动生成:不是唯一的操作模式，但如果您选择，Alembic将读取应用程序的sqlalchemy配置(例如，设置所有表，约束和映射的声明性模型类)并与实际当前表进行比较状态，并输出一个Python脚本来表示两者之间的差异.然后，您将该脚本传递给Alembic的upgrade命令，然后您就可以解决差异.通常，需要手动编辑少量迁移脚本，这只是(a)迁移的本质，以及(b)无论如何都要执行的操作，以确保您完全了解迁移的确切步骤.在运行之前要执行.

Autogeneration: Not its only mode of operation, but if you choose, Alembic will read your application's sqlalchemy configuration (for instance, your declarative model classes that set up all your tables, constraints, and mappings) and compare to the actual current state of your database, and output a Python script that represents the delta between the two. You then pass that script to Alembic's upgrade command and there you go, the differences are resolved. A small amount of editing the migration script by hand is usually needed, and that's (a) just the nature of migrations, and (b) something you want to do anyway to make sure you were fully aware of the exact steps that the migration is going to perform before you run it.

Alembic还为跟踪迁移提供了类似DVCS的功能.它使返回数据库模式的任何过去状态变得非常容易.

Alembic brings a DVCS-like ability to the way your migrations are tracked, too. It makes it really easy to return to any past state of your db schema.

这篇关于值得使用sqlalchemy-migrate吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！