来自Hibernate会话的JPA风格的Criteria/CriteriaBuilder查询

Question

我有一个使用Hibernate 4.x的应用程序，它当前正在使用本机Hibernate API（这意味着我有一个sessionFactory和session)。我刚刚注意到，现有的标准API被弃用了，而支持JPA的（高级）标准API：

Hibernate提供了一个旧的、遗留的org.Hibernate.criteriaAPI，应该将其视为不推荐使用的API。任何特性开发都不会针对这些API。最终，特定于Hibernate的条件特性将作为JPAjavax.persistence.criteria.CriteriaAquery的扩展进行移植。

我不想将我的应用html" target="_blank">程序转换为直接使用EntityManager（尽管很容易从那里获得Hibernatesession)，因为我们有大量的自定义Hibernate配置逻辑需要替换。尽管如此，我还是希望开始使用JPA标准API，因为旧的API已经被弃用了（如果过去的Hibernate版本可以说明问题，那么在将来可能会随机消失），而且它们还提供了更好的类型安全性。

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

Answer 1

我们的项目也有同样的困境。项目真的很复杂：90%的实体是动态生成的；在Hibernate标准API之上实现了API层、重DAO层和服务层，应用非常广泛；我们的hibernate版本经过多次补丁，以支持特定功能（如以/通过连接、oracle中的数组类型等）；同时使用postgresql和oracle,等等。

新的JPA API对我们非常有用。我们需要在标准API（而不是HQL）级别使用函数的能力（例如出于某种性能原因的NVL/Coalesce、Substring、Trim等等）。此外，我们需要Hibernate Envers，它仅可用于“EntityManager”JPA实现。

不幸的是，根据我们的研究结果，根本无法使用来自原生Hibernate的JPA标准API。Envers也不能使用。Hibernate项目正在不断发展并获得新的特性。迁移到新的hibernate版本对我们来说是非常复杂的任务。并且我们非常担心无法使用迁移后新版本的许多新特性并与这个基本框架一起成长。

因此，我们考虑了两种可能的方法：将SQLCriterial与自己的Expression实现一起使用（使用CriteriaQuery解析列名并转换为SQL)，或者迁移到“EntityManager”/CriteriaBuilder。第二条路看起来是不可避免的。但是向JPA实现的迁移带来了许多隐藏的问题，这些问题破坏了我们的项目。

如果我们选择迁移并且它将是有用的，那么我将在这里留下我们将在本活动中挣扎的问题。