从 Hibernate 4 迁移到 5 [英] Migration from Hibernate 4 to 5

问题描述

我尝试迁移到使用 Hibernate 5 的 Spring Boot 1.4.我有一些包含表创建的 MariaDB 数据库的备份脚本.

I try to migrate to Spring Boot 1.4 that uses Hibernate 5. I have some backup script of a MariaDB database that includes table creation.

由于 Spring Boot 中的 spring-data-jpa，我的实体使用以下 id 生成策略.

Due to spring-data-jpa in Spring Boot my entities are using the following id generation strategy.

@GeneratedValue(strategy = GenerationType.AUTO)

在我的 application.properties 我有

spring.jpa.generate-ddl=true
spring.jpa.hibernate.use-new-id-generator-mappings=false

Hibernate 团队一般不推荐这个设置(假值).

The Hibernate team generally don’t recommend this setting (false value).

如果我让 hibernate 生成表，似乎与备份脚本中的有些不同.

If I let hibernate generate the table, seem some differences with the one in the backup script.

如果我对生成器使用 false 值并使用备份脚本并在之后设置为 true，我会遇到一些关于外键的问题

If I use false value about the generator and use the backup script and set after that to true, I get some issue about oreign key

无法添加或更新子行:外键约束失败...

Cannot add or update a child row: a foreign key constraint fail...

如果我一直为 false，我会得到相同的结果.

I get same result if I keep to false.

我可以使用什么策略迁移到 Hibernate 5 的新生成器并拥有旧数据库的数据(不是结构)?

What strategy can I use to migrate to new generator of Hibernate 5 and have data of my old database (not the structure)?

有没有办法保持更通用?不特定于 Hibernate

Is there a way to stay more generic? not specific to Hibernate

推荐答案

您面临的问题是在 Hibernate 4 及更早版本中，使用 GenerationType.AUTO 暗示如果您连接到的数据库支持 IDENTITY 或 AUTO_INCREMENT 数据类型，这些数据类型比使用基于表的序列更受欢迎.

The issue you face is that in Hibernate 4 and prior, using GenerationType.AUTO implied that if the database you're connected to supported IDENTITY or AUTO_INCREMENT data types, those would be preferred over using table-based sequences.

对于 Hibernate 5，GenerationType.AUTO 将默认使用基于表的序列来处理以前使用 IDENTITY 或 AUTO_INCREMENT 的数据库.逻辑变化的原因有点复杂，但足以说明有更好的选择.

With Hibernate 5, GenerationType.AUTO will default to using table-based sequences for databases that previously would have used IDENTITY or AUTO_INCREMENT. The reason for the logic change is a bit complex, but suffice to say there are better alternatives.

我的建议是多步迁移路径，因为这会很乏味，具体取决于表的大小和数量以及实体之间的关系.

My suggestion would be a multi-step migration path because this is going to be tedious depending on the size and number of tables and relationships between your entities.

1. 首先，不要使用新的标识符映射生成器(例如使用 false).
2. 验证一切正常，即现状.
3. 更改所有 @GeneratedValue 注释以使用 GenerationType.IDENTITY.
4. 更改为使用标识符映射生成器(例如，使用 true).
5. 验证一切正常，即现状.

1. First, don't use the new identifier mapping generators (e.g. use false).
2. Verify everything works, aka status-quo.
3. Change all your @GeneratedValue annotations to use GenerationType.IDENTITY.
4. Change to use identifier mapping generators (e.g. use true).
5. Verify everything works, aka status-quo.

在这一点上，您不必更改数据库中的任何内容，它与备份中的一样珍贵.您所做的只是迁移了 java 代码，以便对于新实体，您可以使用新的标识符映射并保留现有实体的旧方式.

At this point, you haven't had to change anything in your database, its stayed preciously as it was from the backup. All you've done is migrated the java code so that for new entities, you can use the new identifier mappings and preserve the old way for existing entities.

从现在开始，我建议一次迁移一个实体.

From this point forward, I would suggest migrating one entity at a time.

1. 更改 java 类以使用由 hibernate_sequences 表支持的命名序列生成器.
2. 确定实体数据的 MAX(ID)，并在 hibernate_sequences 表中为该实体的命名标识符设置适当的下一个 id 值.
3. 这里乏味的部分是您需要删除与该实体现有 ID 列相关的所有外键，更改其数据类型，使其不是 AUTO_INCREMENT 或 IDENTITY 而是最有可能的类似 BIGINT 或 INT 的东西.然后你想把外键约束放回去.

1. Change the java class to use a named sequence generator backed by the hibernate_sequences table.
2. Determine the MAX(ID) of your entity's data and set the appropriate next id value in the hibernate_sequences table for that entity's named identifier.
3. The tedious part here is you'll need to drop all your foreign keys related to this entity's existing ID column, alter its data type so that it isn't AUTO_INCREMENT or IDENTITY but instead most likely something like BIGINT or INT. Then you want to put the foreign key constraints back.

此时，该实体应该开始使用序列表的逻辑，而不是 AUTO 之前使用的本机 AUTO_INCREMENT 或 IDENTITY 功能休眠 5.

At this point, that entity should begin using the sequence table's logic rather than the native AUTO_INCREMENT or IDENTITY functionality that AUTO used prior to Hibernate 5.

对于大型、复杂的系统，这不会很有趣.

For large, complex systems, this won't be fun.

我必须评估我们是否在过去的项目中适应 ORM5 中的新标识符事物，并且我们确定适应复杂的现有模式所花费的时间不值得.我们最终做了前 1-5 个步骤以保持现状，然后允许新实体利用新东西.该计划是让开发人员随着时间的推移根据需要返回并完成最后 1-3 个步骤.

I had to evaluate whether we adapted to the new identifier things in ORM5 for a past project and we determined the time involved to adapt a complex, existing schema wasn't worth it. We ended up doing the first 1-5 steps to remain status-quo and then allowed new entities to leverage the new stuff. The plan was for developers go back and finish the last 1-3 steps on an as-needed basis over time.

这篇关于从 Hibernate 4 迁移到 5的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！