是否值得使用 sqlalchemy-migrate ？ [关闭]

Question

我有一个使用 sqlalchemy（在 Pylons 内）的 Web 应用程序。我需要有效地更改架构，以便能够至少每天更改生产版本，也许更多，而不会丢失数据。

我在周末玩了一点 sqlalchemy-migrate，我想说它给我留下了不好的印象。首先我认为这无助于两个数据库引擎之间的迁移；这可能只用 sqlalchemy 就可以完成。 其次，文档似乎不是最新的。我不得不更改一些命令行选项，例如在每个命令中提供存储库路径，这可能是迁移的错误。

但最糟糕的是“manage.py test”命令。不仅它实际上修改了数据库（这一点在文档中明确指出，所以我不能责怪迁移）而且我的第一个迁移脚本只是进行了简单愚蠢的模式迁移，使升级降级的数据库与与原始架构不同的架构。但是“manage.py 测试”只是回答了类似

 success !

也就是说，它甚至不检查模式是否保持一致状态。 那么值得使用 migrate 吗？ 与与良好实践相关的 Do It Yourself 方法as proposed by S.Lott 相比，有什么优势吗？ 是否有替代 sqlalchemy-migrate 的方法实际上简化了迁移过程，或者我只是想用一个不好的 priori 来使用 migrate （然后请告诉我为什么不明显优于按照上面的链接）？

非常感谢！

Answer 1

改用 Alembic：

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

感谢 cmets，编辑添加一些推理 --

它是由 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 保持同步的能力充满信心（以前就是这种情况）。

Answer 3

我个人喜欢使用它。这太棒了，因为新安装（开发、测试、产品）可以很容易地引导。不仅如此，随着应用程序的增长，它还为应用程序提供了一个归宿，并为在应用程序版本之间迁移时需要进行的迁移提供了良好的入口点。需要在开发、测试和生产服务器上执行更改/等操作。

完美吗？没有。你可以让你的数据库处于糟糕的状态，但这就是你拥有开发/测试/生产版本的原因。

我个人使用它来引导我在 pylons 中的单元测试，使用 sqlite db 来运行单元测试，但我们在生产中使用 mysql。所以使用它有一些跨数据库平台的优势。