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

Question

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

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

谢谢.

Answer 1

我同意你的理念.

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

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

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

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