我有一个使用sqlalchemy（在Pylons中）的Web应用程序。我需要有效地更改架构，以便至少每天更改生产版本，可能更多，而不会丢失数据。
我在周末与sqlalchemy-migrate进行了一些比赛，我会说这给我留下了不好的印象。首先我认为它无法帮助两个数据库引擎之间的迁移;这可能只能通过sqlalchemy完成。 其次，文档似乎不是最新的。我不得不更改一些命令行选项，比如在每个命令中给出存储库路径，这可能是迁移的错误。
但最糟糕的是“manage.py 测试”命令。它不仅实际上修改数据库（这一点在文档中清楚地表明，所以我不能责怪迁移）但是我的第一个迁移脚本只是做了简单的愚蠢模式迁移，而保留了降级后的数据库与原始不同的架构。但是“manage.py测试”只回答了类似
的问题 success !
也就是说，它甚至没有检查架构是否处于连贯状态。 那么是否值得使用迁移？与优秀做法as proposed by S.Lott相关的“自己动手”方法相比，是否有任何优势？ 是否有sqlalchemy-migrate的替代方案实际上简化了迁移过程，或者我只是尝试使用错误的先验进行迁移（然后请告诉我为什么不明显优于创建CSV列，如上面的链接）？
非常感谢！
答案 0 :(得分：68)
改为使用Alembic：
http://pypi.python.org/pypi/alembic
感谢您的评论，编辑后添加了一些推理 -
它是由SQLAlchemy的作者开发的，它是全新的并得到很好的支持。我不太了解sqlalchemy-migrate来进行比较。但我快速阅读了简明扼要的Alembic文档，然后在很短的时间内完成了自己的自动生成迁移。
自动生成：不是唯一的操作模式，但如果您选择，Alembic将读取您的应用程序的sqlalchemy配置（例如，设置所有表，约束和映射的声明性模型类）并与实际当前进行比较数据库的状态，并输出表示两者之间的增量的Python脚本。然后，您将该脚本传递给Alembic的升级命令，然后您就可以解决差异了。通常需要手动编辑少量迁移脚本，这是（a）迁移的本质，以及（b）您想要做的事情，以确保您完全了解迁移的确切步骤在你运行它之前去执行。
Alembic也为您的迁移跟踪方式带来了类似DVCS的能力。它使返回到数据库模式的任何过去状态变得非常容易。
答案 1 :(得分：8)
Alembic离开（http://pypi.python.org/pypi/alembic）并由SQLAlchemy作者维护，并且鉴于sqlalchemy-migrate开发看起来停滞不前，今年几乎没有提交（http://code.google.com/p/sqlalchemy-migrate/source/list），我认为不值得使用它 ，我会将当前的项目切换到Alembic。
如果仍然需要大量维护，我会对项目与SQLAlchemy保持同步的能力充满信心（之前的情况就是如此）。
答案 2 :(得分：3)
我个人喜欢使用它。这很棒，因为新安装（dev，test，prod）可以非常容易地进行自举。不仅如此，它还为应用程序的发展提供了一个家，并为您在应用程序的版本之间移动时需要进行的迁移提供了良好的切入点。有些东西需要在开发，测试和生产服务器上执行alter / etc。
完美吗？不。你可以让你的数据库处于不良状态，但这就是你拥有开发/测试/生产版本的原因。
我个人使用它来使用sqlite db来引导我在柱子中进行单元测试以运行单元测试，但我们在生产中使用mysql。所以有一些跨数据库平台使用它的优点。