我有一个使用 sqlalchemy 的 Web 应用程序（在 Pylons 内）。我需要有效地更改架构，以便能够至少每天（甚至更多）更改生产版本，而不会丢失数据。
周末我玩了一点 sqlalchemy-migrate，我想说它给我留下了不好的印象。第一的我认为它无法帮助两个数据库引擎之间的迁移;这可能可以单独使用 sqlalchemy 来完成。
其次，文档似乎不是最新的。我必须更改一些命令行选项，例如在每个命令中给出存储库路径，这可能是迁移的错误。
但最糟糕的是“manage.pytest“命令。实际上不仅如此修改数据库（这一点在文档中清楚地指出，所以我不能责怪迁移）但是我的第一个迁移脚本只是进行了简单的愚蠢的模式迁移，留下了升级降级的数据库与原始架构不同。但“manage.py 测试”只是回答了类似的问题
success !
也就是说，它甚至没有检查模式是否处于一致状态。
所以值得使用迁移吗？与良好实践相关的“自己动手”方法相比，是否有任何优势根据 S.Lott 的建议 https://stackoverflow.com/questions/4165452/how-to-efficiently-manage-frequent-schema-changes-using-sqlalchemy/4165496#4165496？
是否有 sqlalchemy-migrate 的替代方案实际上简化了迁移过程，或者我只是尝试使用 migrate 来进行糟糕的操作priori（那么请告诉我为什么没有明显优于上面链接中建议的创建 CSV 列）？
非常感谢！
使用 Alembic 代替：
http://pypi.python.org/pypi/alembic http://pypi.python.org/pypi/alembic
感谢您的评论，编辑添加一些推理 -
它是由SQLAlchemy的作者开发的，是全新的并且得到很好的支持。我对 sqlalchemy-migrate 的了解不够，无法进行很好的比较。但我快速阅读了清晰简洁的 Alembic 文档，然后在很短的时间内让我自己的自动生成的迁移工作起来。
自动生成：不是唯一的操作模式，但如果您选择，Alembic 将读取应用程序的 sqlalchemy 配置（例如，设置所有表、约束和映射的声明性模型类）并与应用程序的实际当前状态进行比较数据库，并输出代表两者之间增量的 Python 脚本。然后，您将该脚本传递给 Alembic 的升级命令，差异就得到解决。通常需要手动编辑少量迁移脚本，这就是 (a) 迁移的本质，以及 (b) 您无论如何都想做的事情，以确保您完全了解迁移的确切步骤将在运行之前执行。
Alembic 还为您的迁移跟踪方式带来了类似 DVCS 的功能。它使您可以轻松返回数据库模式的任何过去状态。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
