首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >什么时候人们应该在JPA2.0中使用原生查询,而不是JPQL或CriteriaBuilder?

什么时候人们应该在JPA2.0中使用原生查询,而不是JPQL或CriteriaBuilder?
EN

Stack Overflow用户
提问于 2012-03-03 22:21:04
回答 1查看 4.2K关注 0票数 9

在JPA2.0中,我对何时以及何时不使用原生查询感到非常困惑。我的印象是,使用原生查询可能会导致我与JPA缓存脱节。如果我可以用JPQL或CriteriaBuilder查询来完成同样的事情,那么使用原生查询有什么好的理由吗?类似地,如果我可以用JPQL或CriteriaBuilder来完成相同的事情,那么使用原生查询有什么危险吗?最后,如果使用原生查询存在与JPA缓存不同步的危险,那么使用JPQL或CriteriaBuilder执行等价的查询也会存在同样的危险吗?

我的哲学一直是避免原生查询,但肯定有必要这样做。在我看来,如果我可以用JPQL或CriteriaBuilder来做这件事,那么我就应该这么做。

谢谢。

EN

回答 1

Stack Overflow用户

回答已采纳

发布于 2012-03-03 23:12:13

我同意你的哲学。

原生查询的主要问题是可维护性。首先,它们通常比JPQL查询更复杂、更长。但它们也硬编码表名和列名,而不是使用类名和属性名。

JPQL查询在重构时已经存在问题,因为它们将类和属性名称硬编码到String中。但是原生查询更糟糕,因为它们到处都是硬编码的表名和列名。

我不认为原生select查询是缓存方面的问题。但是,原生更新、插入和删除查询是一个问题,因为它们在一级和二级缓存后面修改数据。所以这些可能会变得陈旧。

另一个问题是,原生查询可能使用一个数据库可以识别但另一个数据库不能识别的语法,这使得应用程序更难从一个数据库迁移到另一个数据库。

票数 14
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/9546806

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档