Nsryjdtyk

I've been wondering which kind of projections should I use, so I did a little test, which covered 5 types of projections (based on docs: https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#projections):

1. Entity projection

This is just a standard findAll() provided by Spring Data repository. Nothing fancy here.

Service:

List<SampleEntity> projections = sampleRepository.findAll();

Entity:

@Entity

@Table(name = "SAMPLE_ENTITIES")

public class SampleEntity {

    @Id

    private Long id;

    private String name;

    private String city;

    private Integer age;

}

2. Constructor projection

Service:

List<NameOnlyDTO> projections = sampleRepository.findAllNameOnlyConstructorProjection();

Repository:

@Query("select new path.to.dto.NameOnlyDTO(e.name) from SampleEntity e")

List<NameOnlyDTO> findAllNameOnlyConstructorProjection();

Data transfer object:

@NoArgsConstructor

@AllArgsConstructor

public class NameOnlyDTO {

    private String name;

}

3. Interface projection

Service:

List<NameOnly> projections = sampleRepository.findAllNameOnlyBy();

Repository:

List<NameOnly> findAllNameOnlyBy();

Interface:

public interface NameOnly {

    String getName();

}

4. Tuple projection

Service:

List<Tuple> projections = sampleRepository.findAllNameOnlyTupleProjection();

Repository:

@Query("select e.name as name from SampleEntity e")

List<Tuple> findAllNameOnlyTupleProjection();

5. Dynamic projection

Service:

List<DynamicProjectionDTO> projections = sampleRepository.findAllBy(DynamicProjectionDTO.class);

Repository:

<T> List<T> findAllBy(Class<T> type);

Data transfer object:

public class DynamicProjectionDTO {



    private String name;



    public DynamicProjectionDTO(String name) {

        this.name = name;

    }

}

Some additional info:

The project was built using gradle spring boot plugin (version 2.0.4), which uses Spring 5.0.8 under the hood. Database: H2 in memory.

Results:

Entity projections took 161.61 ms on average out of 100 iterations.

Constructor projections took 24.84 ms on average out of 100 iterations.

Interface projections took 252.26 ms on average out of 100 iterations.

Tuple projections took 21.41 ms on average out of 100 iterations.

Dynamic projections took 23.62 ms on average out of 100 iterations.

-----------------------------------------------------------------------

One iteration retrieved (from DB) and projected 100 000 objects.

-----------------------------------------------------------------------

Notes:

It is understandable that retrieving entities takes some time. Hibernate tracks these objects for changes, lazy loading and so on.

Constructor projections are really fast and have no limitations on the DTO side, but require manual object creation in @Query annotation.

Interface projections turned out to be really slow. See question.

Tuple projections were the fastest, but are not the most convinient to play with. They need an alias in JPQL and the data has to be retrieved by calling .get("name") instead of .getName().

Dynamic projections look pretty cool and fast, but must have exactly one constructor. No more, no less. Otherwise Spring Data throws an exception, because it doesn't know which one to use (it takes constructor parameters to determine which data to retrieve from DB).

Question:

Why interface projections take longer than retrieving entities? Each interface projection returned is actually a proxy. Is it so expensive to create that proxy? If so, doesn't it defeat the main purpose of projections (since they are meant to be faster than entities)? Other projections look awesome tho. I would really love some insight on this. Thank you.

EDIT :
Here is the test repository: https://github.com/aurora-software-ks/spring-boot-projections-test in case you want to run it yourself. It is very easy to set up. Readme contains everything you need to know.

I experienced similar behavior with an older version of Spring Data and this was my take on it: https://blog.arnoldgalovics.com/how-much-projections-can-help/

I had a talk with Oliver Gierke (Spring Data lead) and he made some improvements (that's why you get so "good" results :-) ) but basically there will be always a cost on having abstractions vs coding it manually.

This is a trade-off as everything else is. On one hand you got flexibility, easier development, less maintenance (hopefully), on the other hand you get full control, a bit uglier query model.