我有一个使用sqlalchemy(在Pylons中)的Web应用程序。我需要有效地更改架构,以便每天至少可以更改生产版本,可能更多,而不会丢失数据。
我已经在周末玩了一下sqlalchemy-migrate,并且我认为它给了我一个不好的印象。首先,我认为它无法帮助在两个数据库引擎之间进行迁移;这可能只能通过sqlalchemy完成。其次,文档似乎不是最新的。我不得不更改一些命令行选项,比如在每个命令中提供存储库路径,这可能是migrate的一个错误。
但最糟糕的是“manage.py test”命令。它不仅实际上修改了数据库(这一点在文档中清楚地指出,所以我不能责怪migrate),而且我的第一个迁移脚本只是做了愚蠢的模式迁移,使升级/降级后的数据库与原始数据库具有不同的架构。但是,“manage.py test”只是回答了一些东西。
那就是说,它甚至没有检查模式是否保持一致的状态。 那么,使用迁移是否值得呢?与S.Lott建议的良好实践所提出的自己动手方法相比,有什么优势吗? 实际上,是否有简化迁移过程的sqlalchemy-migrate替代方案,或者我只是试图在先入为主的情况下使用migrate(然后请告诉我为什么它明显优于如上链接中提出的创建CSV列)? 非常感谢!
我已经在周末玩了一下sqlalchemy-migrate,并且我认为它给了我一个不好的印象。首先,我认为它无法帮助在两个数据库引擎之间进行迁移;这可能只能通过sqlalchemy完成。其次,文档似乎不是最新的。我不得不更改一些命令行选项,比如在每个命令中提供存储库路径,这可能是migrate的一个错误。
但最糟糕的是“manage.py test”命令。它不仅实际上修改了数据库(这一点在文档中清楚地指出,所以我不能责怪migrate),而且我的第一个迁移脚本只是做了愚蠢的模式迁移,使升级/降级后的数据库与原始数据库具有不同的架构。但是,“manage.py test”只是回答了一些东西。
success !
那就是说,它甚至没有检查模式是否保持一致的状态。 那么,使用迁移是否值得呢?与S.Lott建议的良好实践所提出的自己动手方法相比,有什么优势吗? 实际上,是否有简化迁移过程的sqlalchemy-migrate替代方案,或者我只是试图在先入为主的情况下使用migrate(然后请告诉我为什么它明显优于如上链接中提出的创建CSV列)? 非常感谢!