Python 值得使用 sqlalchemy-migrate 吗？

Is it worth using sqlalchemy-migrate ?

提问by ascobol

I have a web application using sqlalchemy (within Pylons). I need to effiently change the schema to be able to change the production version at least on a daily basis, maybe more, without losing the data.

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

I have played a little bit with sqlalchemy-migrate over the week-end and I would say that it gave me a bad impression. First I think it cannot help with migration between two databases engines; that's something that could probably be done with sqlalchemy alone. Second the docs do not seem up to date. I had to change some command-line options, like giving the repository path at each command, this could be a bug of migrate.

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

But the worst thing it the "manage.py test" command. Not only it actually modifies the database(this point is clearly indicated in the documentation so I can't blame migrate) but my first migration script just made plain stupid schema migration, leaving the upgraded-downgraded db with a different schema than the original. But the "manage.py test" just answered something like

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

 success !

That is, it did not even check if the schema was left in a coherent state. So is it worth using migrate?Is there any advantage compared to the Do It Yourself method associated with good practices as proposed by S.Lott? Are there alternatives to sqlalchemy-migrate actually simplifying the migration process or am I just trying to use migrate with a bad a priori(then please show me why is't clearly superior to creating CSV columns as proposed in the link above)?

也就是说，它甚至不检查模式是否处于一致状态。那么值得使用迁移吗？与S.Lott 提出的与良好实践相关的自己动手方法相比，有什么优势吗？是否有替代 sqlalchemy-migrate 的替代方案实际上简化了迁移过程，或者我只是尝试使用 migrate 与一个不好的先验（然后请告诉我为什么不明显优于上面链接中建议的创建 CSV 列）？

Many Thanks!

非常感谢！

采纳答案by cdaddr

Use Alembic instead:

改用 Alembic：

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

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

Thanks for comments, edited to add some reasoning --

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

It's developed by the author of SQLAlchemy, and it's brand new and well supported. I don't know enough about sqlalchemy-migrate to give a good comparison. But I took a quick read through the clear and concise Alembic docs, then got my own autogenerated migration working in a very short time.

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

Autogeneration: Not its only mode of operation, but if you choose, Alembic will read your application's sqlalchemy configuration (for instance, your declarative model classes that set up all your tables, constraints, and mappings) and compare to the actual current state of your database, and output a Python script that represents the delta between the two. You then pass that script to Alembic's upgrade command and there you go, the differences are resolved. A small amount of editing the migration script by hand is usually needed, and that's (a) just the nature of migrations, and (b) something you want to do anyway to make sure you were fully aware of the exact steps that the migration is going to perform before you run it.

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

Alembic brings a DVCS-like ability to the way your migrations are tracked, too. It makes it really easy to return to any past state of your db schema.

Alembic 也为跟踪迁移的方式带来了类似于 DVCS 的功能。它可以很容易地返回到数据库模式的任何过去状态。

回答by Rick

I personally love using it. It's awesome because new installs (dev, test, prod) can be bootstrapped very easily. Not only that, but it provides a home for the app as it grows and provides good entry points for those migrations that need to take place as you move from version to version of your application. Something needs to perform the alter/etc on dev, testing, and production servers.

我个人喜欢使用它。这很棒，因为可以非常轻松地引导新安装（开发、测试、生产）。不仅如此，它还为应用程序的发展提供了一个家，并为在您从应用程序的一个版本移动到另一个版本时需要进行的那些迁移提供了良好的切入点。需要在开发、测试和生产服务器上执行更改/等操作。

Is it perfect? Nope. You can leave your db in a bad state, but that's why you have dev/testing/production versions of things.

它是完美的吗？不。你可以让你的数据库处于糟糕的状态，但这就是为什么你有开发/测试/生产版本的东西。

Personally I use it to bootstrap my unit tests in pylons using an sqlite db for running unit tests against, but we use mysql in production. So there are some cross db platform advatages of using it.

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

回答by Kel Solaar

Alembic being out ( http://pypi.python.org/pypi/alembic) and maintained by SQLAlchemy author and given the fact that sqlalchemy-migrate development looks stalled, with practically no commits this year ( http://code.google.com/p/sqlalchemy-migrate/source/list), I think it's not worth using it anymore, I'll switch my current project to Alembic.

Alembic 出局 ( http://pypi.python.org/pypi/alembic) 并由 SQLAlchemy 作者维护，鉴于 sqlalchemy-migrate 开发看起来停滞不前，今年几乎没有提交 ( http://code.google. COM / p / SQLAlchemy的，迁移/源/列表），我认为这是不值得使用它了，我就转我的当前项目蒸馏器。

If it was still heavily maintained, I would be confident on the ability of the project to keep synchronised with SQLAlchemy ( Which was the case before ).

如果它仍然得到大量维护，我会对项目与 SQLAlchemy 保持同步的能力充满信心（以前就是这种情况）。