Решите, какой класс владеет стороной в Hibernate - PullRequest
Новая
       8

Решите, какой класс владеет стороной в Hibernate

2 голосов
/ 18 марта 2020

У меня есть Role класс, который является основной сущностью для ролей пользователя, и 2 FK в этой таблице, которые независимо указаны в двух словарях: Privelege и Unit классы.

Так что, как я понимаю, это множество (Role) к одному (Privelege / Unit).

Вопрос:

  1. Правильно ли отображение Hibernate в моем коде?

  2. Какой класс является "владельцем" в моем случае и почему?

  3. В каком классе я должен написать @JoinColumn и где mappedBy?

Как я прочитал в других сообщениях: «@JoinColumn аннотация поддерживается в классе, который владеет внешним ключом.»

Но в do Hibernate c я вижу, что mappedBy используется на стороне владельца (см. Пример 163. Двунаправленный @OneToOne). 4. Что произойдет, если я удалю некоторые записи Role? Если я удалю некоторые записи из словарей, повлияет ли это на записи Role? Могу ли я переопределить это поведение, чтобы отключить каскадирование?

Я предполагаю, что мой класс "Роль" является стороной-владельцем, потому что он имеет FK, указывающий на 2 словаря. Так что он владеет ФК. Поэтому мне нужно использовать @JoinColumn здесь в качестве своей собственной стороны и mappedBy в двух словарях, потому что это отображается по собственной стороне. Я прав.

Обновление: является ли синоним «стороны-владельца» «родительской стороне»?

Класс роли 

@Entity
@Table(name="ROLES_NEW", schema="MAPP")
public class Role implements GrantedAuthority {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "ID", nullable = false)
    private Long id;

    @Column(name = "ROLENAME")
    private String roleName;

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "UNIT_ID")
    private Unit unit;

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "PRIVELEGE_ID")
    private Privelege privelege;

...

}

Класс Privelege 


@Entity
@Table(name="PRIVELEGES", schema="MAPP")
public class Privelege /*implements GrantedAuthority*/ {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "ID", nullable = false)
    private Long id;

    @Column(name = "PRIVELEGENAME", length = 255, nullable = false)
    private String privelegeName;

    @Column(name = "descr", length = 255, nullable = false)
    private String descr;

    @OneToMany(mappedBy = "privelege")
    Set<Role> role;

...

}

Класс устройства 

@Entity
@Table(name="UNITS", schema="MAPP")
public class Unit {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "ID", nullable = false)
    private Long id;

    @Column(name = "UNITNAME")
    private String unitname;

    @OneToMany(mappedBy = "unit")
    Set<Role> role;

   ...

}

1 Ответ

1 голос
/ 18 марта 2020

Да, дочерняя сущность владеет отношениями, потому что это сторона, на которой находится внешний ключ. Это отображение наиболее эффективно в случае @ManyToOne.

То же самое применимо к отношениям "многие ко многим", отображаемым как два двунаправленных @ManyToOne. Это также может быть сделано с аннотацией @JoinTable, но этот подход менее эффективен.

В случае @OneToOne, хотя дочерний элемент (владелец внешнего ключа) владеет отношением, наилучшую производительность можно получить при использовании @MapsId и @JoinColumn на родительской стороне. Подробнее об этом исключении можно узнать здесь .

Когда дело доходит до mappedBy, это просто - оно используется, когда отношение является двунаправленным, а на стороне @JoinColumn - нет (у ребенка @JoinColumn, у родителя - mappedBy).

Я рекомендую блог Влада Михалчеа, когда речь идет об оптимальном отображении гибернации: один-ко-многим , многие-ко-многим .

PS: Предпочитают List -1030 * сопоставлять отношение-ко-многим ( источник ).

...