来自Hibernate会话的JPA样式条件/CriteriaBuilder查询
我有一个使用Hibernate 4.x的应用程序，它目前正在使用本机Hibernate API(这意味着我有一个SessionFactory和Session)。我只是表示反对现有的标准API，以支持JPA的(高级)标准API：
Hibernate提供了一个旧的、遗留的
org.hibernate.CriteriaAPI，应该被认为是不推荐的。没有任何特性开发会针对这些API。最终，Hibernate特有的标准特性将被移植为JPAjavax.persistence.criteria.CriteriaQuery的扩展。
我不想将我的应用程序转换成直接使用EntityManager (尽管从那里很容易获得Hibernate Session )，因为我们有大量需要替换的自定义Hibernate配置逻辑。尽管如此，我肯定想开始使用JPA标准API，因为旧的API被废弃了(如果过去的Hibernate版本有任何迹象，它可能会在将来的某个随机点消失)，而且它们还提供了更好的类型安全性。
如果我使用的是工厂/会话，我如何使用新的CriteriaQuery/CriteriaBuilder？
回答 1
Stack Overflow用户
发布于 2015-08-12 16:20:24
在我们的项目中，我们也面临着同样的困境。该项目非常复杂: 90%的实体是动态生成的；在Hibernate标准API、heavy和服务层之上实现了API级别，使用非常广泛；我们的hibernate版本经过多次修补以支持特定的功能(如START WITH/CONNECT BY、oracle中的ARRAY类型等)；postgresql和oracle可交替使用等等。
新的JPA将对我们非常有用。我们需要在标准API (而不是HQL)级别使用函数的能力(比如NVL/coalesce，因为某种性能原因，substring，trim等等)。此外，我们需要Hibernate Envers，它只适用于"EntityManager“JPA实现。
不幸的是，根据我们的研究结果，根本没有能力使用来自本机Hibernate的JPA标准API。不能再用了。Hibernate项目正在不断发展，并获得了新的特性。迁移到新的hibernate版本对我们来说是非常复杂的任务。我们非常担心在迁移之后无法使用新版本的许多新特性，并在这个基本框架中成长。
因此，我们考虑了两种可能的方法:将SQLCriterion与Expression的实现结合使用(用CriteriaQuery解析列名并转换为CriteriaQuery)或迁移到"EntityManager“/ CriteriaBuilder。第二条路看起来是不可避免的。但是，向JPA实现的迁移带来了许多隐藏的问题，破坏了我们的项目。
如果我们选择迁移，并且它将是有用的，我将在这里留下我们将在这个活动中解决的问题。
https://stackoverflow.com/questions/14406185
复制相似问题
腾讯云开发者
