同一实体的对象之间的多对多关系的 JPA 注释

发布于 2024-12-06 07:50:42 字数 1349 浏览 0 评论 0原文

我想实现一个角色层次结构,但对 JPA 注释相当陌生。

我有一个带有名称和 ID 的角色实体(通过 AbstractPersistable 隐式):

@Entity
@Table(name="role")
public class Role extends AbstractPersistable<Long> {
    private static final long serialVersionUID = 8127092070228048914L;  
    private String name;

现在我希望能够定义以下关系:

  • 一个角色可以有许多子角色
  • 一个角色可以是许多角色的子角色角色

我该如何使用 Hibernate 注释来做到这一点?我可以在角色实体中定义它吗?

@ManyToMany(cascade = CascadeType.MERGE)
@JoinTable( name = "role_hierarchy", 
            joinColumns = { @JoinColumn(name = "role_id")}, 
            inverseJoinColumns={@JoinColumn(name="child_role_id")})  
private List<Role> roles;

@ManyToMany(cascade = CascadeType.MERGE)
@JoinTable( name = "role_hierarchy", 
            joinColumns = { @JoinColumn(name = "child_role_id")}, 
            inverseJoinColumns={@JoinColumn(name="role_id")})  
private List<Role> children;

我走在正确的轨道上吗?我缺少什么?

非常感谢您的帮助!


编辑: - 已解决,因此已删除 -


编辑2:

看起来我的应用程序堆栈中有一些错误。在模型定义级别上,role_hierarchy 运行得很好,所以不用介意编辑 1...

但是:两种方法似乎都有效(即创建 m:n 表条目、级联删除和检索实体的父级和子级) ):

  • 我建议在 @ManyToMany 注释处为没有 mappedBy 属性的双方定义一个连接列
  • ,并定义拥有方和反方。

有什么区别?有关系吗?

I want to implement a Role Hierarchy but am rather new to JPA Annotations.

I have a Role Entity with a name and an id(implicit via AbstractPersistable):

@Entity
@Table(name="role")
public class Role extends AbstractPersistable<Long> {
    private static final long serialVersionUID = 8127092070228048914L;  
    private String name;

Now I want to be able to define the following relationships:

  • a Role can have many child roles
  • a Role can be child to many roles

How would I do that with Hibernate annotations? Can I define this inside the Role Entity

@ManyToMany(cascade = CascadeType.MERGE)
@JoinTable( name = "role_hierarchy", 
            joinColumns = { @JoinColumn(name = "role_id")}, 
            inverseJoinColumns={@JoinColumn(name="child_role_id")})  
private List<Role> roles;

@ManyToMany(cascade = CascadeType.MERGE)
@JoinTable( name = "role_hierarchy", 
            joinColumns = { @JoinColumn(name = "child_role_id")}, 
            inverseJoinColumns={@JoinColumn(name="role_id")})  
private List<Role> children;

Am I on the right track? What am I missing?

Thank's a lot for your help!


EDIT: - removed as it has been solved -


EDIT 2:

Looks like I have some bug in my application stack. On the model defining level the role_hierarchy is working out just fine, so never mind EDIT 1...

BUT: Both ways seem to work (that is createing the m:n table entry, cascading delete and retrieval of parents and children for an entity):

  • my proposal of defining a join column for both sides with no mappedBy property at the @ManyToMany annotation
  • as well as defining an owning side and an inverse side.

What's the difference? Does it matter?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

耳根太软 2024-12-13 07:50:42

双向关系由拥有方和反向方组成。

在拥有方,您声明关系的物理属性:

@ManyToMany(cascade = CascadeType.MERGE)
@JoinTable(name = "role_hierarchy", 
            joinColumns = { @JoinColumn(name = "role_id")}, 
            inverseJoinColumns={@JoinColumn(name="child_role_id")})  
private List<Role> roles;

在反面,您使用 mappedBy 属性指向相应的拥有方:

@ManyToMany(cascade = CascadeType.MERGE, mappedBy = "roles")
private List<Role> children;    

对于多对多关系,哪一方是所属方并不重要拥有方(只要您一致地修改双方,因为只有拥有方的更改才会传播到数据库)。

另请参阅:

Bidirectional relationship consists of owning and inverse sides.

At the owning side you declare physical properties of the relationship:

@ManyToMany(cascade = CascadeType.MERGE)
@JoinTable(name = "role_hierarchy", 
            joinColumns = { @JoinColumn(name = "role_id")}, 
            inverseJoinColumns={@JoinColumn(name="child_role_id")})  
private List<Role> roles;

At the inverse side you point at the corresponding owning side with mappedBy attribute:

@ManyToMany(cascade = CascadeType.MERGE, mappedBy = "roles")
private List<Role> children;    

For many-to-many relationships it doesn't matter which side is the owning side (as long as you modify both sides consistently, since only changes at the owning side are propagated to the database).

See also:

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文