为什么加载相关实体上的惰性字段

Question

In my REST API project (Java 8, Spring Boot 2.3.1) I have a problem with some queries triggering massive query chains by loading lazy relations, even though the related objects are never accessed.

I have a UserEntity and a polymorphic CompanyEntity that are related with a ManyToMany relationship. I have an endpoint that returns all users and I include the IDs of the related companies in the JSON. I excpect a query to the user table and a query to the company table, however all related entities of one sub-entity of CompanyEntity are always loaded for each of those sub-entities resulting in large query chains.

Here are snippets of my classes:

User entity

@Entity(name = "USERS")
public class UserEntity {

  @Id
  @GeneratedValue
  private UUID id;

  @EqualsAndHashCode.Exclude
  @Fetch(FetchMode.SUBSELECT)
  @ManyToMany(fetch = FetchType.LAZY)
  @JoinTable(
      name = "users_company",
      joinColumns = @JoinColumn(name = "USER_ID"),
      inverseJoinColumns = @JoinColumn(name = "COMPANY_ID")
  )
  private Set<CompanyEntity> companies = new HashSet<>();

  public List<UUID> getCompanyIds() {
    return companies.stream()
        .map(CompanyEntity::getId)
        .collect(Collectors.toList());
  }

}

Polymorphic company entity

@Entity(name = "COMPANY")
@Inheritance(strategy = InheritanceType.JOINED)
public abstract class CompanyEntity {

  @Id
  @GeneratedValue
  private UUID id;

  @Fetch(FetchMode.SUBSELECT)
  @ManyToMany(mappedBy = "companies", fetch = FetchType.LAZY)
  private Set<UserEntity> users = new HashSet<>();
}

Concrete company subclass that triggers the problem

@Entity(name = "CUSTOMER")
public class CustomerEntity extends CompanyEntity {

  @NotNull
  @OneToOne(cascade = {CascadeType.PERSIST, CascadeType.MERGE}, fetch = FetchType.LAZY)
  private ContactPersonEntity contactPerson;

  @Fetch(FetchMode.SUBSELECT)
  @OneToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE}, fetch = FetchType.LAZY, mappedBy = "customer")
  private Set<TransactionEntity> transactions = new HashSet<>();

  public Set<UUID> getTransactionIds() {
    return this.transactions.stream()
        .map(TransactionEntity::getId)
        .collect(Collectors.toSet());
  }
}

In the REST controller I return the following mapping:

@GetMapping(value = "", produces = MediaType.APPLICATION_JSON_VALUE)
public List<UserReadModel> getUsers() {
  return userRepository.findAll().stream()
      .map(userEntity -> new UserReadModel(userEntity))
      .collect(Collectors.toList());
}

Where the UserReadModel is a DTO:

@Data
public class UserReadModel {

  private UUID id;
  private List<UUID> companyIds;

}

Logging the database queries results in the following output:

// Expected
Hibernate: select userentity0_.id as id1_47_, ... from users userentity0_
Hibernate: select companies0_.user_id ... case when companyent1_1_.id is not null then 1 when companyent1_2_.id is not null then 2 when companyent1_.id is not null then 0 end as clazz_0_ from users_company companies0_ inner join company companyent1_ on companies0_.company_id=companyent1_.id left outer join customer companyent1_1_ on companyent1_.id=companyent1_1_.id left outer join external_editor companyent1_2_ on companyent1_.id=companyent1_2_.id where companies0_.user_id in (select userentity0_.id from users userentity0_)

// Unexpected as they are marked lazy and never accessed
Hibernate: select contactper0_.id ... from contact_person contactper0_ where contactper0_.id=?
Hibernate: select transactio0_.customer_id ... from transactions transactio0_ where transactio0_.customer_id=?
Hibernate: select contactper0_.id ... from contact_person contactper0_ where contactper0_.id=?
Hibernate: select transactio0_.customer_id ... from transactions transactio0_ where transactio0_.customer_id=?
...

I've read through loads of articles on entity mapping and lazy loading but I can't seem to find a reason why this behavior persists. Did anyone have this problem before?

Answer 1

You are accessing the collection, so Hibernate has to load the collection. Since you only need the ids and already have a DTO, I think this is a perfect use case forBlaze-Persistence Entity Views .

I created the library to allow easy mapping between JPA models and custom interface or abstract class defined models, something like Spring Data Projections on steroids. The idea is that you define your target structure(domain model) the way you like and map attributes(getters) via JPQL expressions to the entity model.

A DTO model for your use case could look like the following with Blaze-Persistence Entity-Views:

@EntityView(UserEntity.class)
public interface UserReadModel {
    @IdMapping
    UUID getId();
    @Mapping("companies.id")
    Set<UUID> getCompanyIds();
}

Querying is a matter of applying the entity view to a query, the simplest being just a query by id.

UserReadModel a = entityViewManager.find(entityManager, UserReadModel.class, id);

The Spring Data integration allows you to use it almost like Spring Data Projections: https://persistence.blazebit.com/documentation/entity-view/manual/en_US/index.html#spring-data-features

Page<UserReadModel> findAll(Pageable pageable);

The best part is, it will only fetch the state that is actually necessary, In your case: a query like the following will be generated:

select u.id, uc.company_id
from users u
left join users_company uc on uc.user_id = u.id
left join company c on c.id = uc.company_id

Depending on the Hibernate version, the join for the company might even be omitted.

Answer 2

I eventually figured out the solution and want to post it here, in case anyone stumbles upon this question. This was purely a mistake on my side and is not reproducible from the examples I posted.

I used lombok annotations to generate equals and hashcode methods on the customer entity (and all other entities for that matter) and forgot to annotate the contactPerson and transactions fields with @EqualsAndHashcode.Exclude . As the equals method was called somewhere along the execution, it triggered the lazy loading of those fields. Implementing equals and hashcode manually and using the guidelines from this article for that solved the problem.