播放、休眠和进化

Question

我以前没有使用过 Liquibase 和类似工具的经验。到目前为止，我通常使用 Hibernate 在应用程序上管理部署到生产环境的方式是使用手动 SQL 来修改表，因为它们是非常简单的应用程序（复杂的应用程序没有使用它......请不要问： P)。

我想在 Play 中使用 Evolutions，但我发现它在开发中与 Hibernate 发生了严重冲突，这使它成为一种痛苦而不是现实的选择。在开发中，Hibernate 可以轻松管理所有内容，因此使用 Evolutions 毫无意义，但我们希望保留结构（文件）以便更轻松地在生产模式下迁移应用程序。但由于冲突，它似乎不值得。

Liquibase 有一个 Play 模块，但它似乎在 Evolutions 发布后就停产了（我想知道为什么，因为我相信它会与 Hibernate 一起工作）。

问题是：

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

Answer 1

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

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

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

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

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

如果能得到反馈，那就太好了。

Answer 2

关于让 hibernate 吐出 SQL 让你开始使用 Evolutions 或 Flyway，看看这个：http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/toolsetguide.html#toolsetguide-s1-6

编辑：我实际上制作了一个插件来引导您的迁移脚本。我认为它可能对遇到此线程的大多数人有用： http://web.ist.utl.pt/~joao.a.p.antunes/2014/08/09/play-2-2-x-jpa-hibernate-database-migration

干杯！

Answer 3

通常的情况是，应用程序在其生命周期中有两个阶段 - 初始开发和后期生产“维护”。我的经验是，所有大型数据库更改通常都发生在第一阶段。依靠 Hibernate 让自己在那里变得灵活，然后当您进入生产环境时，您可以进行模式转储，使用 Evolutions 将其滚动到生产环境，然后从那里手动管理您的 DDL。

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

（话虽如此 - 我希望 Evolutions 和 Play/Hibernate 更好地集成，比如可以选择记录 Hibernate 吐出到 Evolutions 目录的 DDL）