java - 遗留 Hibernate 应用程序的预期升级路径是什么？

Question

我最近有幸获准在中型遗留代码库(从 3.x 到 5.2)中更改 Hibernate 依赖项(以及其他)的版本。代码本身已有 10 多年的历史，但仍在日常使用中。

因此，即使在增加版本并将尽可能多的 API 调用从现在已弃用甚至缺失的区域移植到最前沿的对应部分(了解如何执行 SchemaExport 是一种特别有趣的体验)后，我仍然不认为这是一个完整的迁移。

我想知道遗留用户的预期升级路径是什么，因为企业系统通常会存在 10 到 15 年以上，但有时您仍然需要跳到更新的依赖版本以获得必要的错误修复或功能。

以下几点还有点悬而未决:

• 没有明确或自动的方法将 .hbm.xml 映射信息迁移到 JPA 注释。我知道手动迁移很容易出错，而且并非所有概念都有清晰或明显的对应部分。

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

• 我们似乎使用了很多 native 查询和 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 -> 数据库，然后使用逆向工程工具从您的数据库模式生成注释。
3. 旧版标准已弃用，因为我们无法再维护两个标准 API。此外，JPA Criteria 更高级(它具有类型安全查询和元模型)。不幸的是，也没有从遗留 API 到 Criteria API 的自动迁移。但是，即使您有数百个这样的方法调用，您也可以轻松地自动 (regex/perl/vi) 或手动迁移它们。不需要那么多时间。
4. ResultTransformer 将被一种可以更好地利用 lambda 的新机制所取代。因此，新接口(interface)或接口(interface)必须是功能接口(interface)。