Problem: we want queries to our entities to eagerly fetch only the fields that we need in the given context (for example to show in a specific UI data table).
Requirement: our solution must be able to accept dynamic filter compositions.
- Named Entity Graphs from the JPA standard
- Projections mechanism from Spring Data
Lets research them!
JPA Named Entity Graphs
This mechanism comes directly from the JPA specifications and is supported by Spring Data repositories. To use it we must first specify a graph on our entity. In that graph we define the fields to be eagerly fetched.
As you can see using entity graphs is trivial in this simple example. However, there is a crucial problem for more complex data models if you choose Hibernate as your JPA implementation. There is a bug hanging around since 2014 which makes using named entity graphs impossible in @Embedded and @MappedSuperclass classes. If you're using another implementation that does not suffer from this limitation then you can read more about entity graphs in the Java EE documentation and the Springs Data documentation.
Spring Data Projections
This is a feature from outside of the JPA specs and is supported only by Spring Data repositories for JPA. It uses interfaces to define the scope of data which you want to be fetched eagerly.
As you can see this solutions returns only an interfaces with the projected fields and not an entity in which you could choose to get other properties using lazy fetching. This can be seen as a downside but in fact its a safer approach if performance is crucial to your app. Spring Data projections also have some interesting additional features that named entity graphs cannot provide. Your can read more about them in the Spring Data JPA Reference Manual.
Usage in dynamic queries
Both mechanisms described in this article require some effort to make them work with dynamic queries constructed by the Specifications mechanism from Spring Data. Normaly we add the specifications mechanism to our repositories by extending the JpaSpecificationExecutor<T> interface which gives a closed set of methods that accept Specification<T> as their argument (optionally with the Pageable and Sort argument). Out of the box Spring Data JPA conventions do not let us to use Specification<T> in our own methods. Because of this we cannot add our own dynamic query methods which would return a projection interface or have an @EntityGraph annotation. To solve this problem we must extend the internals of Spring Data - fortunately there are working third party libraries that do just that.
This article is a result of our cooperation with Nextbuy - a SaaS company which develops a procurement and online auction platform to connect buyers and suppliers. We provide various consulting and software development services to them and they have kindly allowed us to publish part of the resulting research / design documents. You can checkout their amazing platform at www.nextbuy24.com
Do you need help in your company with some topic we mentioned in our blog articles? If so, then please feel free to contact us. We can help you by providing consulting and audit services or by organizing training workshops for your employees. We can also aid you in software development by outsourcing our developers.