旧版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-to-Annotations工具。但是，还有另一种选择。你可以做HBM - ＆gt;数据库，然后使用反向工程工具从数据库模式生成注释。
3. 旧版条件已弃用，因为我们无法再承担维护两个Criteria API的费用。此外，JPA Criteria更先进（它具有类型安全查询和Metamodel）。遗憾的是，也没有从遗留系统到Criteria API的自动迁移。但是，即使你有数百个这样的方法调用，你也可以自动（regex / perl / vi）或手动迁移它们。这样做不会那么多。
4. ResultTransformer将被一种可以更好地利用lambdas的新机制所取代。因此，新的接口或接口必须是功能接口。