找公司做网站源代码给客户吗,慈溪app开发公司,财务公司经营范围,摄影作品欣赏网站Criteria API对于动态构建查询非常有用#xff0c;但这是我使用它的唯一用例。 每当您有一个带有N个过滤器且可以以任意M个组合到达的UI时#xff0c;就应该有一个API动态地构造查询#xff0c;因为连接字符串始终是我所不愿使用的路径。 问题是#xff0c;您是否知道您的… Criteria API对于动态构建查询非常有用但这是我使用它的唯一用例。 每当您有一个带有N个过滤器且可以以任意M个组合到达的UI时就应该有一个API动态地构造查询因为连接字符串始终是我所不愿使用的路径。 问题是您是否知道您的Criteria API在后台生成SQL查询 最近我一直在审查许多这样的查询而弄错它的难易程度令我震惊。 让我们从以下实体图开始 因此我们有一个产品其中ToOne与WareHouseProductInfo关联而ToMany与Image实体关联。 现在让我们从以下Criteria API查询开始 CriteriaBuilder cb entityManager.getCriteriaBuilder();
CriteriaQueryProduct query cb.createQuery(Product.class);
RootProduct 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();
CriteriaQueryProduct query cb.createQuery(Product.class);
RootProduct productRoot query.from(Product.class);
JoinProduct, 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();
CriteriaQueryProduct query cb.createQuery(Product.class);
RootProduct product query.from(Product.class);
query.select(product);
query.distinct(true);ListPredicate criteria new ArrayListPredicate();
criteria.add(cb.like(cb.lower(product.get(Product_.name)), %tv%));SubqueryLong subQuery query.subquery(Long.class);
RootImage infoRoot subQuery.from(Image.class);
JoinImage, Product productJoin infoRoot.join(product);
subQuery.select(productJoin.Longget(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();
CriteriaQueryProduct query cb.createQuery(Product.class);
RootImage imageRoot query.from(Image.class);
JoinImage, Product productJoin imageRoot.join(product);
query.select(productJoin);
query.distinct(true);
ListPredicate criteria new ArrayListPredicate();
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();
CriteriaQueryImageProductDTO query cb.createQuery(ImageProductDTO.class);
RootImage imageRoot query.from(Image.class);
JoinImage, Product productJoin imageRoot.join(Image_.product);
query.distinct(true);
ListPredicate criteria new ArrayListPredicate();
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.imageJOIN PUBLIC.productON 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并且SQL功能将比Hibernate当前提供的功能更多。 因此只要您的用例不需要查询托管实体就可以使用JOOQ。 我之所以喜欢它是因为我可以比使用Criteria API更好地预测生成SQL并且当更易于使用API时等待“哇”的“惊喜”就会减少。 代码可在GitHub上获得 。 参考 Hibernate Fact始终在Vlad Mihalcea的Blog博客上从我们的JCG合作伙伴 Vlad Mihalcea 检查Criteria API SQL查询 。 翻译自: https://www.javacodegeeks.com/2013/12/hibernate-facts-always-check-criteria-api-sql-queries.html
