hibernate - 来自 Hibernate Session 的 JPA 样式 Criteria/CriteriaBuilder 查询

Question

我有一个使用 Hibernate 4.x 的应用程序，它目前正在使用本机 Hibernate API（这意味着我有 aSessionFactory和Sessions）。我刚刚注意到现有的 Criteria API 已被弃用，取而代之的是 JPA 的（高级）Criteria API：

Hibernate 提供了一个较旧的遗留org.hibernate.CriteriaAPI，应被视为已弃用。没有功能开发将针对这些 API。最终，特定于 Hibernate 的标准特性将被移植为 JPA 的扩展javax.persistence.criteria.CriteriaQuery。

我不想将我的应用程序转换为EntityManager直接使用（即使Session从那里很容易获得 Hibernate），因为我们有大量需要替换的自定义 Hibernate 配置逻辑。尽管如此，我肯定想开始使用 JPA Criteria API，因为旧的 API 已被弃用（如果过去的 Hibernate 版本有任何迹象，可能会在未来的某个随机点消失）并且它们还提供了更好的类型安全性。

如果我使用的是 SessionFactory/Session，如何使用新的 CriteriaQuery/CriteriaBuilder API？

Answer 1

我们的项目也有同样的困境。项目真的很复杂：90%的实体都是动态生成的；在Hibernate标准API之上实现了API级别，重DAO和服务层，应用非常广泛；我们的 hibernate 版本经过多次修补以支持特定功能（如START WITH/ CONNECT BY，ARRAY输入 oracle 等）；交替使用 postgresql 和 oracle 等。

新的 JPA API 对我们非常有用。我们需要能够在 Criteria API（而不是 HQL）级别使用函数（例如NVL/coalesce出于某种性能原因，substring等等trim）。此外，我们需要仅可用于“ EntityManager”JPA 实现的 Hibernate Envers。

不幸的是，根据我们的研究结果，根本无法使用原生 Hibernate 中的 JPA Criteria API。Envers 也不能用。Hibernate 项目不断发展并获得新功能。迁移到新的休眠版本对我们来说是非常复杂的任务。并且我们非常担心迁移后无法使用新版本的许多新功能并随着这个基本框架成长。

因此，我们考虑了两种可能的方式：使用SQLCriterion自己的Expressions 实现（使用解析列名CriteriaQuery并转换为 SQL）或迁移到 " EntityManager" / CriteriaBuilder。第二种方式看起来是不可避免的。但是迁移到 JPA 实现带来了许多隐藏的问题，这些问题破坏了我们的项目。

如果我们选择迁移并且它会很有用，我将在这里留下我们将在此活动中遇到的问题。