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

Question

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

我的理念是确实避免本地查询，但肯定有些时候它们是必要的。在我看来，如果我可以使用 JPQL 或 CriteriaBuilder 来做到这一点，那么我应该这样做。

谢谢。

Answer 1

我同意你的哲学。

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

JPQL 查询在重构时已经存在问题，因为它们在字符串中硬编码类和属性名称。但是原生查询更糟糕，因为它们到处都对表名和列名进行硬编码。

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

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