旧版Hibernate应用程序的预期升级路径是什么？

Question

我最近有幸被允许在中等大小的遗留代码库(从3.x到5.2)中破坏Hibernate依赖版本(以及其他版本).代码本身已有超过10年的历史,但仍在日常使用中.

因此,即使在增加版本并将尽可能多的API调用从现在已弃用甚至丢失的区域转移到他们的前沿对手(找到如何进行SchemaExport是一种特别有趣的体验)之后,我仍然不认为这是一个完整的迁移.

我想知道遗留用户的预期升级路径是什么,因为企业系统通常会持续10到15年以上,有时您需要跳转到较新的依赖版本以获取必要的错误修正或功能.

以下几点仍然有些开放:

• 没有明确或自动的方法将.hbm.xml映射信息迁移到JPA注释.我知道手动迁移将非常容易出错,并非所有概念都有明确或明显的反向部分.

• 我们现在收到很多关于我们使用旧Criteria API的弃用警告(org.hibernate.orm.deprecation),但是也没有明确的升级路径.人们不能仅仅将应用程序的整个数据库访问代码重写为完全不同且更详细的API,这些API在某些边缘情况下肯定会表现不同.

• 我们似乎使用了大量的原生查询和实例org.hibernate.transform.ResultTransformer然而,org.hibernate.query.Query#setResultTransformer()似乎没有指示如何解决这个被弃用.

一般来说,我发现有关Hibernate方面的弃用和预期升级路径的文档很少见.我确实知道它是一个开源项目,并且他们不想永远维护旧的API,但我仍感到有些迷失,我不相信这是唯一仍在使用的遗留Java应用程序今天.

Answer 1

我明白你的意思。事实上，我最近在我们的论坛上看到了有关从 3.x 迁移到 4.x 和 5.x 的各种问题。

1. 我认为我们应该有一个迁移登陆页面作为每次迁移的起始页面。这样，用户将必须转到单个页面并找到他们需要的所有内容。
2. 我们没有自动 HBM 到注释工具。然而，还有一个替代方案。您可以执行 HBM -> 数据库，然后使用逆向工程工具从数据库模式生成注释。
3. 旧 Criteria 已被弃用，因为我们无法再维护两个 Criteria API。另外，JPA Criteria 更先进（它具有类型安全查询和元模型）。不幸的是，也没有从旧 API 到 Criteria API 的自动迁移。但是，即使您有数百个此类方法调用，您也可以轻松地自动（regex/perl/vi）或手动迁移它们。不需要花那么多时间就能做到。
4. 该ResultTransformer机制将被一种可以更好地利用 lambda 的新机制所取代。因此，一个或多个新接口必须是功能接口。