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

Question

我有一个使用 Hibernate 4.x 的应用程序，它目前正在使用 native Hibernate API(意味着我有一个 SessionFactory 和 Session s)。我只是noticed不推荐使用现有的 Criteria API 以支持 JPA 的(高级)Criteria API:

Hibernate offers an older, legacy org.hibernate.Criteria API which should be considered deprecated. No feature development will target those APIs. Eventually, Hibernate-specific criteria features will be ported as extensions to the JPA javax.persistence.criteria.CriteriaQuery.

我不想将我的应用程序转换为使用 EntityManager直接(即使很容易从那里获得 Hibernate Session)，因为我们有大量需要替换的自定义 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 等)。
此外，我们需要 Hibernate Envers，它仅适用于“EntityManager”JPA 实现。

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

因此，我们为我们考虑了两种可能的方法:使用 SQLCriterion自己实现 Expression s(使用 CriteriaQuery 解析列名并转换为 SQL)或迁移到“EntityManager”/CriteriaBuilder .第二种方式看起来不可避免。但是迁移到 JPA 实现带来了许多隐藏的问题，这些问题毁了我们的项目。

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