什么时候应该使用JPA 2.0而不是JPQL或CriteriaBuilder的本机查询?

时间:2012-03-03 14:21:04

标签: jpa-2.0 jpql native-sql

我对在JPA 2.0中何时以及何时不使用本机查询感到困惑。我的印象是使用本机查询可能会导致我与JPA缓存不同步。如果我可以使用JPQL或CriteriaBuilder查询完成同样的事情,是否有充分的理由使用本机查询?同样,如果我可以使用JPQL或CriteriaBuilder完成同样的事情,那么使用本机查询是否有任何危险?最后,如果使用本机查询存在危险,与JPA缓存不同步,使用JPQL或CriteriaBuilder执行等效查询是否存在同样的危险?

我的理念是避免本地查询,但肯定有时候它们是必要的。在我看来,如果我可以使用JPQL或CriteriaBuilder,那么我应该。

感谢。

1 个答案:

答案 0 :(得分:13)

我同意你的理念。

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

重构时,JPQL查询已经存在问题,因为它们会对字符串中的类和属性名称进行硬编码。但是本机查询更糟糕,因为它们在任何地方都对表名和列名进行硬编码。

我不认为本机选择查询是关于缓存的问题。但是,本机更新,插入和删除查询是一个问题,因为它们会修改第一级和第二级缓存后面的数据。所以这些可能会变得陈旧。

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