玩,休眠和进化

Question

我以前没有像Liquibase等类似工具的经验.到目前为止,我通常使用Hibernate在应用程序上部署生产的方式是使用手动SQL来修改表,因为它们是非常简单的应用程序(复杂的应用程序没有使用它...请不要问: P).

我想在Play中使用Evolutions,但我发现它在开发过程中与Hibernate发生了很大的冲突,这让它变得很痛苦而且不是一个现实的选择.在开发过程中,Hibernate很容易管理所有内容,因此没有必要使用Evolutions,但我们希望保留结构(文件),以便在生产模式下更轻松地迁移应用程序.但由于冲突,它似乎并不值得.

Liquibase有一个Play模块,但是自从Evolutions发布以来它似乎已经停止了(我想知道为什么,因为我相信它会对Hibernate产生影响).

问题是:

• 如何管理生产中的应用程序的数据库迁移？
• 当您的模型在发行版之间进行更改并且必须部署到生产环境时,您使用的常用过程/步骤是什么？
• 我们忽略了Hibernate的任何特定工具或功能,或者只是老忠实的SQL Alter表和类似的？
• 专注于Play Framework,您如何管理？

Answer 1

通常的情况是,应用程序在其生命周期中有两个阶段 - 初始开发和后期制作"维护".我的经验是,所有大型数据库更改通常都会在第一阶段发生.通过依赖Hibernate让自己变得灵活,然后当你去生产时,你会采用模式转储,使用Evolutions在生产中滚动它,并从那里手动管理你的DDL.

在第二个"阶段"(我是一个敏捷的人,我讨厌这个词;-)),模式更改通常也包括DML,因为你必须计算新列的初始值,等等.此外,您通常会花费更多时间在编码上而不是模式更改上,因此整个手动体验变得不那么痛苦了:).

(话虽如此 - 我喜欢Evolutions和Play/Hibernate之间更好的集成,比如可以选择记录Hibernate吐出到evolutions目录的DDL)

Answer 2

嗯，你问了一个很好的问题。我在 grails 上遇到了这个问题，所以我没有真正的解决方案，但有一些想法。我将从 Evolutions 与 Liquibase 的比较开始：

1. Liquibase 是一个成熟的解决方案，即使插件不再开发，底层库就是它。所以我认为这是一个可以接受的解决方案。
2. 如果您使用 Evolution，与 liquibase 相比，您有一个很大的缺点：您必须直接编写 SQL，因此脚本取决于您的数据库系统。考虑布尔值和不同数据库中的表示。所以你失去了 Hibernate 给你带来的好处。

现在讨论一般问题。我认为你必须选择：

1. 让 Hibernate 为您处理数据库结构。只有在 Hibernate 无法完成这项工作的情况下，您才使用 liquibase 或进化。不幸的是，如果您有复杂的更新场景，您可能会遇到一些麻烦。无论你如何获胜，你的发展都会更快。
2. 您忽略 Hibernate 中的所有 DDL 功能，并使用 liquibase 或进化来完成所有操作。这是最可靠、最强大的解决方案，但显然您还有更多的开发工作要做。

那么我的建议是什么？我会尝试以下方法：使用分布式版本控制系统（例如 bzr 或 git）进行开发。然后使用功能分支。功能分支始终使用休眠功能。在将内容合并到主干之前，创建 liquibase-script。这些脚本可以由 liquibase 通过一些手动定制来生成）。因此，您可以非常快速地开发一个功能，并且始终拥有强大的解决方案 2。但是请注意，这在伟大的项目中并不是经过验证的方法。我只在一个小项目上使用 Hibernate 和 Liquibase 测试了这个策略 - 它工作得很好。

所以如果能得到反馈就太好了。