当前位置: 首页 > 面试题库 >

Spring Data REST的QueryDSL集成可以用于执行更复杂的查询吗?

狄誉
2023-03-14
问题内容

我目前正在构建一个REST API,我希望客户端可以在其中轻松过滤特定实体的大多数属性。通过将QueryDSL与Spring Data REST结合使用,我可以通过允许客户端通过组合引用属性(例如/users?firstName=Dennis&lastName=Laumen)的查询参数进行过滤,轻松达到我想要的90%。

我什至可以通过实现QuerydslBinderCustomizer接口来自定义查询参数与实体属性之间的映射(例如,不区分大小写的搜索或部分字符串匹配)。一切都很好,但是我也希望客户端能够使用范围过滤某些类型。例如,关于诸如出生日期之类的属性,我想执行以下操作/users?dateOfBirthFrom=1981-1-1&dateOfBirthTo=1981-12-31。基于数字的属性也是如此/users?idFrom=100&idTo=200。我觉得使用QuerydslBinderCustomizer接口应该可以实现这一点,但是这两个库之间的集成并未得到广泛的记录。

最后,使用Spring Data REST和QueryDSL是否可能?如果是这样,怎么办?


问题答案:

我认为你应该可以使用以下定制功能使它起作用:

bindings.bind(user.dateOfBirth).all((path, value) -> {

  Iterator<? extends LocalDate> it = value.iterator();
  return path.between(it.next(), it.next());
});

此处的关键是使用?dateOfBirth=…&dateOfBirth=(使用属性两次)和….all(…)绑定,该绑定将使你能够访问提供的所有值。

确保将@DateTimeFormat注释添加到的dateOfBirth-property中,User以便Spring能够正确地将输入内容Strings转换为LocalDate实例。

目前,lambda得到了a Collection<? extends T>,这使理清各个元素变得更加痛苦,但我认为我们可以在将来的版本中对此进行更改以更合理地暴露a List



 类似资料:
  • 我目前正在构建一个REST API,我希望客户机能够在其中轻松地过滤特定实体的大多数属性。将QueryDSL与Spring Data REST结合使用(Oliver Gierke的一个示例),允许客户机通过组合引用属性的查询参数(例如)进行筛选,从而使我可以轻松地获得我想要的内容的90%。 我甚至可以通过实现接口(例如,对于不区分大小写的搜索或部分字符串匹配)自定义查询参数和实体属性之间的映射。这

  • 问题 您要执行的 SQL 语句如:高级的联接或计数。 方案 webpy 没有尝试在数据库之上建立一层模型,而是以尽可能简单的方式查询数据库, 做复杂的查询也很容易。例如: import web db = web.database(dbn='postgres', db='mydata', user='dbuser', pw='') # Query number of entries in `us

  • 通过一些重要的挖掘,我们发现spring-data-rest with query-dsl可以让REST API客户机轻松地过滤实体的大多数属性。 这个问题也很有用:Spring Data REST的QueryDSL集成是否可以用于执行更复杂的查询?

  • 问题内容: 我正在构建一个将获得大量流量的PHP应用程序。我一直了解到,我应该限制SQL查询的数量(目前,每个访问者大约有15个)。我可以将其限制为使用PHP进行数据过滤和排序的一半左右,但这会更快吗?另外,我可以在查询中使用“ JOIN”来减少查询数量,但这真的比执行多个查询快吗?谢谢! 问题答案: 如果每个访问者有15个查询,则除非您的应用程序很大,否则您很可能做错了什么。 使用PHP而不是M

  • 例如,JPA标准API可以在没有生成元模型的情况下使用。失去了类型安全性,但我可以在运行时仅使用反射来创建查询,而无需事先了解数据模型。我想以同样的方式使用Querydsl。我不关心类型安全问题,因为我不知道数据模型。 在我最近的项目中,我想使用Querydsl,主要是因为它构成了持久性之上的另一层。所以我希望可以在JPA、JDO、JDBC、Lucene、Hibernate Search、Mong

  • 我是JPA/JPQL的新手,所以如果这个问题不是很清楚,请原谅。 我正在使用以下JPQL查询: 查询在无状态会话上运行,以便获得DB中当前数据的事实上的快照,该快照与实体管理器分离(因此使用了left join fetch)。 不幸的是,我遇到了两个问题: 在尝试微调性能时,使用本机查询似乎并没有比使用JPQL查询更好的性能。使用本机查询也会产生对象类型的结果,这需要后期处理。