Thanks for comments, edited to add some reasoning --
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.
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 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.
If it was still heavily maintained, I would be confident on the ability of the project to keep synchronised with SQLAlchemy ( Which was the case before ).
I personally love using it. It's awesome because new installs (dev, test, prod) can be bootstrapped very easily. Not only that, but it provides a home for the app as it grows and provides good entry points for those migrations that need to take place as you move from version to version of your application. Something needs to perform the alter/etc on dev, testing, and production servers.
Is it perfect? Nope. You can leave your db in a bad state, but that's why you have dev/testing/production versions of things.
Personally I use it to bootstrap my unit tests in pylons using an sqlite db for running unit tests against, but we use mysql in production. So there are some cross db platform advatages of using it.
发布评论
评论（3）
使用 Alembic 代替：
http://pypi.python.org/pypi/alembic
感谢您的评论，已编辑以添加一些推理--
由SQLAlchemy作者开发，全新且支持良好。我对 sqlalchemy-migrate 的了解不够，无法进行很好的比较。但我快速阅读了清晰简洁的 Alembic 文档，然后在很短的时间内让我自己的自动生成的迁移工作起来。
自动生成：这不是唯一的操作模式，但如果您选择，Alembic 将读取应用程序的 sqlalchemy 配置（例如，设置所有表、约束和映射的声明性模型类）并与应用程序的实际当前状态进行比较数据库，并输出代表两者之间增量的 Python 脚本。然后，您将该脚本传递给 Alembic 的升级命令，差异就得到解决。通常需要手动编辑少量迁移脚本，这就是 (a) 迁移的本质，以及 (b) 您无论如何都想做的事情，以确保您完全了解迁移的确切步骤将在运行之前执行。
Alembic 还为您的迁移跟踪方式带来了类似 DVCS 的功能。它使您可以轻松返回数据库模式的任何过去状态。
Use Alembic instead:
http://pypi.python.org/pypi/alembic
Thanks for comments, edited to add some reasoning --
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.
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 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.
Alembic 已退出 ( http://pypi.python.org/pypi/alembic ) 并由SQLAlchemy 作者，鉴于 sqlalchemy-migrate 开发看起来陷入停滞，今年几乎没有提交（ http://code.google.com/p/sqlalchemy-migrate/source/list ），我认为它不再值得使用它，我将切换我当前的项目到蒸馏器。
如果它仍然得到大量维护，我对该项目与 SQLAlchemy 保持同步的能力充满信心（之前就是这种情况）。
Alembic being out ( http://pypi.python.org/pypi/alembic ) and maintained by SQLAlchemy author and given the fact that sqlalchemy-migrate development looks stalled, with practically no commits this year ( http://code.google.com/p/sqlalchemy-migrate/source/list ), I think it's not worth using it anymore, I'll switch my current project to Alembic.
If it was still heavily maintained, I would be confident on the ability of the project to keep synchronised with SQLAlchemy ( Which was the case before ).
我个人很喜欢使用它。这太棒了，因为新安装（开发、测试、生产）可以非常轻松地引导。不仅如此，它还为应用程序的成长提供了一个家，并为您在应用程序的不同版本之间迁移时需要进行的迁移提供了良好的入口点。需要在开发、测试和生产服务器上执行更改/等操作。
完美吗？没有。您可以让数据库处于不良状态，但这就是为什么您有开发/测试/生产版本的原因。
就我个人而言，我使用它来引导我的单元测试，使用 sqlite 数据库来运行单元测试，但我们在生产中使用 mysql。因此使用它有一些跨数据库平台的优点。
I personally love using it. It's awesome because new installs (dev, test, prod) can be bootstrapped very easily. Not only that, but it provides a home for the app as it grows and provides good entry points for those migrations that need to take place as you move from version to version of your application. Something needs to perform the alter/etc on dev, testing, and production servers.
Is it perfect? Nope. You can leave your db in a bad state, but that's why you have dev/testing/production versions of things.
Personally I use it to bootstrap my unit tests in pylons using an sqlite db for running unit tests against, but we use mysql in production. So there are some cross db platform advatages of using it.