Can Spring Data REST's QueryDSL integration be used to perform more complex queries?

Dennis Laumen picture Dennis Laumen · Feb 2, 2016 · Viewed 10.3k times · Source

I'm currently building a REST API in which I want clients to easily filter on most properties of a specific entity. Using QueryDSL in combination with Spring Data REST (an example by Oliver Gierke) allows me to easily get to 90% of what I want by allowing clients to filter by combining query parameters which refer to properties (e.g. /users?firstName=Dennis&lastName=Laumen).

I can even customize the mapping between the query parameters and an entity's properties by implementing the QuerydslBinderCustomizer interface (e.g. for case insensitive searches or partial string matches). This is all great, however I also want the clients to be able to filter some types using ranges. For example with regards to a property like date of birth I'd like to do something like the following, /users?dateOfBirthFrom=1981-1-1&dateOfBirthTo=1981-12-31. The same goes for number based properties, /users?idFrom=100&idTo=200. I have the feeling this should be possible using the QuerydslBinderCustomizer interface but the integration between these two libraries isn't documented very extensively.

Concluding, is this possible using Spring Data REST and QueryDSL? If so, how?

Answer

Oliver Drotbohm picture Oliver Drotbohm · Feb 2, 2016

I think you should be able to get this to work using the following customization:

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

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

The key here is to use ?dateOfBirth=…&dateOfBirth= (use the property twice) and the ….all(…) binding which will give you access to all values provided.

Make sure you add the @DateTimeFormat annotation to the dateOfBirth-property of User so that Spring is able to convert the incoming Strings into LocalDate instances correctly.

The lambda currently gets a Collection<? extends T> which makes untangling the individual elements a bit more pain that it needs to be, but I think we can change this in a future release to rather expose a List.