是否值得使用sqlalchemy-migrate？

Question

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

我在周末用sqlalchemy-migrate进行了一些玩法,我会说这给我留下了不好的印象.首先,我认为它无法帮助两个数据库引擎之间的迁移 ; 这可能只能通过sqlalchemy完成.其次,文档似乎不是最新的.我不得不更改一些命令行选项,比如在每个命令中给出存储库路径,这可能是迁移的错误.

但最糟糕的是它是"manage.py test "命令.它不仅实际修改了数据库(文档中明确指出了这一点,所以我不能责怪迁移),但是我的第一个迁移脚本只是进行了简单的模式迁移,使升级后的数据库与原始数据库的模式不同.但是"manage.py测试"只回答了类似的问题

 success !

也就是说,它甚至没有检查架构是否处于连贯状态.那么迁移是否值得？与S.Lott提出的良好实践相关的"自己动手"方法相比,是否有任何优势？是否有sqlalchemy-migrate的替代方案实际上简化了迁移过程,或者我只是尝试使用先验不好的迁移(那么请告诉我为什么不明显优于创建上面链接中提出的CSV列)？

非常感谢!

Answer 1

请改用Alembic:

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

感谢您的评论,编辑添加一些推理 -

它是由SQLAlchemy的作者开发的,它是全新的并得到很好的支持.我不太了解sqlalchemy-migrate来进行比较.但我快速阅读了清晰简洁的Alembic文档,然后在很短的时间内完成了自己的自动生成迁移.

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

Alembic也为您的迁移跟踪方式带来了类似DVCS的能力.它使返回到数据库模式的任何过去状态变得非常容易.

Answer 2

Alembic正在退出(http://pypi.python.org/pypi/alembic)并由SQLAlchemy作者维护,并且鉴于sqlalchemy-migrate开发看起来停滞不前,今年几乎没有提交(http://code.google. com/p/sqlalchemy-migrate/source/list),我认为不再使用它了,我会将当前项目切换到Alembic.

如果它仍然得到很大程度的维护,我会对项目与SQLAlchemy保持同步的能力充满信心(之前就是这种情况).