
您面临的问题是在Hibernate
4和更低版本中,使用
GenerationType.AUTO表示如果您将数据库连接到支持的
IDENTITY或
AUTO_INCREMENT数据类型,则将优先使用基于表的序列。
使用Hibernate
5时,
GenerationType.AUTO将默认对以前使用
IDENTITY或的数据库使用基于表的序列
AUTO_INCREMENT。逻辑更改的原因有点复杂,但足以说有更好的选择。
我的建议是采用多步骤迁移路径,因为根据表的大小和数量以及实体之间的关系,这将很繁琐。
- 首先,不要使用新的标识符映射生成器(例如use
false
)。 - 验证一切正常,又称现状。
- 更改所有
@GeneratedValue
注释以使用GenerationType.IDENTITY
。 - 更改为使用标识符映射生成器(例如use
true
)。 - 验证一切正常,又称现状。
在这一点上,您不必更改数据库中的任何内容,它像从备份中一样保留了宝贵的时间。您所做的全部工作就是迁移了Java代码,以便对于新实体,您可以使用新的标识符映射并为现有实体保留旧的方式。
从现在开始,我建议一次迁移一个实体。
- 更改java类以使用
hibernate_sequences
表支持的命名序列生成器。 - 确定实体数据的 MAX(ID) 并在
hibernate_sequences
表中为该实体的命名标识符设置适当的下一个ID值。 - 这里的乏味部分是,您需要删除与该实体的现有 ID 列相关的所有外键,更改其数据类型,以使其不是
AUTO_INCREMENT
或IDENTITY
相反,很可能是BIGINT
或INT
。然后,您想放回外键约束。
此时,该实体应该开始使用序列表的逻辑,而不是使用Hibernate 5之前的本机
AUTO_INCREMENT或
IDENTITY功能
AUTO。
对于大型,复杂的系统,这不会很有趣。
我必须评估我们是否为过去的项目适应了ORM5中的新标识符,并且我们确定适应一个复杂的现有模式所花费的时间是不值得的。我们结束了前1-5步以保持现状,然后允许新实体利用新事物。该计划是供开发人员随时间推移并根据需要完成最后的1-3个步骤。
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)