Criteria API对于动态构建查询非常有用，但这是我使用它的唯一用例。 每当您有一个带有N个过滤器且可以以任意M个组合到达的UI时，都有一个API动态构造查询是有意义的，因为串联字符串始终是我所不愿使用的路径。

问题是，您是否知道您的Criteria API在后台生成的SQL查询？ 最近，我一直在审查许多这样的查询，而弄错它的难易程度令我震惊。

让我们从以下实体图开始：

因此，我们有一个产品，其中ToOne与WareHouseProductInfo关联，而ToMany与Image实体关联。

现在让我们从以下Criteria API查询开始：

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<Product> query = cb.createQuery(Product.class);
Root<Product> productRoot = query.from(Product.class);query.select(productRoot).where(cb.and(cb.equal(productRoot.get(Product_.code), "tvCode"), cb.gt(productRoot.get(Product_.warehouseProductInfo)
.get(WarehouseProductInfo_.quantity), 50)));
Product product = entityManager.createQuery(query).getSingleResult();

您能发现以前的查询有任何问题吗？ 让我们检查一下生成的SQL：

SELECT product0_.id          AS id1_14_,product0_.code        AS code2_14_,product0_.company_id  AS company_5_14_,product0_.importer_id AS importer6_14_,product0_.name        AS name3_14_,product0_.version     AS version4_14_
FROM   product product0_CROSS JOIN warehouseproductinfo warehousep1_
WHERE  product0_.id = warehousep1_.idAND product0_.code = ?AND warehousep1_.quantity > 50

我期待一个INNER JOIN，而我却得到了CROSS JOIN。 笛卡尔积是非常低效的，这就是如果您忘记正确加入对使用where子句进行过滤感兴趣的关联时所得到的。 因此，编写Criteria API毕竟不是在公园里散步。

幸运的是，此示例可以固定如下：

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<Product> query = cb.createQuery(Product.class);
Root<Product> productRoot = query.from(Product.class);
Join<Product, WarehouseProductInfo> warehouseProductInfoJoin = productRoot.join(Product_.warehouseProductInfo);query.select(productRoot).where(cb.and(cb.equal(productRoot.get(Product_.code), "tvCode"),cb.gt(warehouseProductInfoJoin.get(WarehouseProductInfo_.quantity), 50)));
Product product = entityManager.createQuery(query).getSingleResult();

产生预期的SQL查询：

SELECT product0_.id          AS id1_14_,product0_.code        AS code2_14_,product0_.company_id  AS company_5_14_,product0_.importer_id AS importer6_14_,product0_.name        AS name3_14_,product0_.version     AS version4_14_
FROM   product product0_INNER JOIN warehouseproductinfo warehousep1_ON product0_.id = warehousep1_.id
WHERE  product0_.code = ?AND warehousep1_.quantity > 50

因此，请注意如何在Criteria API中定义联接。 现在，让我们将先前的Criteria API查询与其对应的JPAQL进行比较：

Product product = entityManager.createQuery("select p " +"from Product p " +"inner join p.warehouseProductInfo w " +"where " +"   p.code = :code and " +"   w.quantity > :quantity ", Product.class)
.setParameter("code", "tvCode")
.setParameter("quantity", 50)
.getSingleResult();

我一直发现JPAQL比Criteria API更具描述性，但是在有些项目中Criteria API是默认的JPA查询机制，因此它不仅用于动态过滤器查询，甚至用于带有固定where子句的查询。

好吧，您最终可以实现相同的结果，但是尽管我可以通过JPAQL预测SQL查询，但是对于Criteria API而言，我却一无所知。 每当我查看一个Criteria查询时，我总是必须运行一个集成测试来检查输出的SQL，因为小的更改确实可以带来很大的不同。

即使强加了Criteria API的用法，考虑到您要格外小心并检查所有查询，您仍然可以解决它。

现在让我们回到我碰巧碰到的最奇特的联接子查询之一（但次优）条件查询。 如果您与许多开发人员一起从事大型项目，则不可避免地会遇到这种类型的构造。 这就是为什么我更喜欢JPAQL而不是Criteria API的另一个原因。 借助JPAQL，您将无法像下面的示例那样使用它：

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<Product> query = cb.createQuery(Product.class);
Root<Product> product = query.from(Product.class);
query.select(product);
query.distinct(true);List<Predicate> criteria = new ArrayList<Predicate>();
criteria.add(cb.like(cb.lower(product.get(Product_.name)), "%tv%"));Subquery<Long> subQuery = query.subquery(Long.class);
Root<Image> infoRoot = subQuery.from(Image.class);
Join<Image, Product> productJoin = infoRoot.join("product");
subQuery.select(productJoin.<Long>get(Product_.id));subQuery.where(cb.gt(infoRoot.get(Image_.index), 0));
criteria.add(cb.in(product.get(Product_.id)).value(subQuery));
query.where(cb.and(criteria.toArray(new Predicate[criteria.size()])));
return entityManager.createQuery(query).getResultList();

我发现仅通过查看它们就很难解析这些类型的查询，但是有一个子选择闻起来像麻烦，所以让我们看一下生成的SQL查询：

SELECT DISTINCT product0_.id          AS id1_14_,product0_.code        AS code2_14_,product0_.company_id  AS company_5_14_,product0_.importer_id AS importer6_14_,product0_.name        AS name3_14_,product0_.version     AS version4_14_
FROM   product product0_
WHERE  ( Lower(product0_.name) LIKE ? )AND ( product0_.id IN (SELECT product2_.idFROM   image image1_INNER JOIN product product2_ON image1_.product_id =product2_.idWHERE  image1_.index > 0) )

尽管某些用例要求使用SQL子查询，但这里完全没有必要，而且只会减慢查询速度。 但是这次我们实际上需要动态过滤查询，因此JPAQL毫无疑问。 解决此问题的唯一方法是编写适当的Criteria查询。

重构后就是这样：

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<Product> query = cb.createQuery(Product.class);
Root<Image> imageRoot = query.from(Image.class);
Join<Image, Product> productJoin = imageRoot.join("product");
query.select(productJoin);
query.distinct(true);
List<Predicate> criteria = new ArrayList<Predicate>();
criteria.add(cb.like(cb.lower(productJoin.get(Product_.name)), "%tv%"));
criteria.add(cb.gt(imageRoot.get(Image_.index), 0));
query.where(cb.and(criteria.toArray(new Predicate[criteria.size()])));
return entityManager.createQuery(query).getResultList();

现在，我们的SQL查询看起来更好了：

SELECT DISTINCT product1_.id          AS id1_14_,product1_.code        AS code2_14_,product1_.company_id  AS company_5_14_,product1_.importer_id AS importer6_14_,product1_.name        AS name3_14_,product1_.version     AS version4_14_
FROM   image image0_INNER JOIN product product1_ON image0_.product_id = product1_.id
WHERE  ( Lower(product1_.name) LIKE ? )AND image0_.index > 0

我想出了为什么开发人员会在这种特定情况下选择子查询的原因，我相信这是因为他不知道他可以通过与JPAQL相似的方式来投影不同于Root的实体。查询。

现在，让我们进行DTO预测，因为有时我们不需要获取整个实体，而只需获取足够的信息即可满足我们的业务需求。 这次我们将创建以下查询：

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<ImageProductDTO> query = cb.createQuery(ImageProductDTO.class);
Root<Image> imageRoot = query.from(Image.class);
Join<Image, Product> productJoin = imageRoot.join(Image_.product);
query.distinct(true);
List<Predicate> criteria = new ArrayList<Predicate>();
criteria.add(cb.like(cb.lower(productJoin.get(Product_.name)), "%tv%"));
criteria.add(cb.gt(imageRoot.get(Image_.index), 0));
query.where(cb.and(criteria.toArray(new Predicate[criteria.size()])));
query.select(cb.construct(ImageProductDTO.class, imageRoot.get(Image_.name), productJoin.get(Product_.name))).orderBy(cb.asc(imageRoot.get(Image_.name)));
return entityManager.createQuery(query).getResultList();

生成干净的SQL：

SELECT DISTINCT image0_.name   AS col_0_0_,product1_.name AS col_1_0_
FROM   image image0_INNER JOIN product product1_ON image0_.product_id = product1_.id
WHERE  ( Lower(product1_.name) LIKE ? )AND image0_.index > 0
ORDER  BY image0_.name ASC

但是，请检查前面的条件查询以了解JOOQ如何构建这样的查询：

jooqContext
.select(IMAGE.NAME, PRODUCT.NAME)
.from(IMAGE)
.join(PRODUCT).on(IMAGE.PRODUCT_ID.equal(PRODUCT.ID))
.where(PRODUCT.NAME.likeIgnoreCase("%tv%")).and(IMAGE.INDEX.greaterThan(0))
.orderBy(IMAGE.NAME.asc())
.fetch().into(ImageProductDTO.class);

这种方式更具可读性，您实际上不必猜测输出的SQL查询是什么，它甚至可以生成绑定参数，我发现它们非常有价值：

SELECT "PUBLIC"."image"."name","PUBLIC"."product"."name"
FROM   "PUBLIC"."image"JOIN "PUBLIC"."product"ON "PUBLIC"."image"."product_id" = "PUBLIC"."product"."id"
WHERE  ( Lower("PUBLIC"."product"."name") LIKE Lower('%tv%')AND "PUBLIC"."image"."index" > 0 )
ORDER  BY "PUBLIC"."image"."name" ASC

结论

我向您展示的第一种情况是我尝试学习Criteria API时犯的第一个错误。 我发现编写此类查询时必须格外小心，因为您很容易获得意外的SQL查询。

如果您选择对所有查询都使用Criteria API，那么您可能也有兴趣检查JOOQ 。 即使您选择JPAQL，只要要构建高级的动态过滤查询，JOOQ都可以为您提供更好的帮助。

您仍将使用流利的API，不会编写任何String，并且可以获得比H​​ibernate当前提供的SQL功能更多的SQL功能。 因此，只要您的用例不需要查询托管实体，就可以使用JOOQ。 我之所以喜欢它，是因为我可以比使用Criteria API更好地预测生成的SQL，并且当API更易于使用时，等待“哇”的“惊喜”就会减少。

代码可在GitHub上获得 。

翻译自: https://www.javacodegeeks.com/2013/12/hibernate-facts-always-check-criteria-api-sql-queries.html