Fetchtype.LAZY ведет себя как Fetchtype.EAGER с отображением OneToOne - PullRequest
Новая
       21

Fetchtype.LAZY ведет себя как Fetchtype.EAGER с отображением OneToOne

0 голосов
/ 29 июня 2018

У меня есть user (user_id PK) сущность, которая имеет One-to-One связь с mentor_profile сущностью. Тогда mentor_profile имеет One-to-Many связь с mentor_history.
Первичный ключ mentor_profile является общим PK из пользовательской таблицы, т.е. user_id. 

@Entity
@Table(name = "user")
public class User {

   @Id
   @GeneratedValue(strategy = IDENTITY)
   @Column(name = "user_id", unique = true, nullable = false)
   private Integer userId;

   @OneToOne(fetch = FetchType.LAZY, mappedBy = "user")
   private MentorProfile mentorProfile;

mentor_profile 

@Entity
@Table(name = "mentor_profile")
public class MentorProfile {

    @GenericGenerator(name = "generator", strategy = "foreign", parameters = @Parameter(name = "property", value = "user"))
    @Id
    @GeneratedValue(generator = "generator")
    @Column(name = "user_id", unique = true, nullable = false)
    private int userId;

    @OneToOne(fetch = FetchType.LAZY)
    @PrimaryKeyJoinColumn
    private User user;

    @Column(name = "is_looking_mentee")
    private Boolean isLookingMentee;

Но когда запускается запрос select на user, все связанные однозначные объекты (с общим ключом пользователя) также выбираются, даже если я использую FetchType> LAZY. 

Hibernate: select user0_.user_id as user_id1_43_, user0_.about as about2_43_ ............ from user user0_ where user0_.first_name=?
Hibernate: select mentorprof0_.user_id as user_id1_29_0_, ............. from mentor_profile mentorprof0_ where mentorprof0_.user_id=?
Hibernate: select trainerpro0_.user_id as user_id1_42_0_, ............. from trainer_profile trainerpro0_ where trainerpro0_.user_id=?

Основная идея этой модели: пользователь может иметь такие же роли, как наставник, например, тренер. И если пользователь является наставником, существуют определенные столбцы для наставника Например, когда он / она начал наставничество, если он доступен для наставничества и т. Д. Так как эти данные являются специфическими для занятости (наставник, тренер), они не могут быть сохранены в таблице пользователей. Поскольку при таком дизайне, если пользователь является наставником, все столбцы, относящиеся к тренеру, будут пустыми, что является плохим дизайном. Согласно высокопроизводительной mysql , всегда следует избегать нулевых значений в БД, они стоят нам памяти и производительности. Поэтому разделение профессии user на xx_profile решает эту проблему.

Это общий ключ, который вызывает проблему?

1 Ответ

0 голосов
/ 29 июня 2018

Ленивый не работает на отображении OneToOne. Лучше смени на @ManyToOne, Lazy будет работать над ним.

...