具有子类型的双向多对多 JPA 映射
我的基本场景是使用 JPA 映射的双向多对多关系。够简单的。但是,我需要向映射添加“类型”,并且我正在努力寻找最佳实现。概要如下:
Network
Set<Member> defaultMembers; //members that meet the network definition
Set<Member> suppressedMembers; //members that meet the network definition, but are hidden.
Set<Member> addedMembers; //memders that don't meet the network definition, but have been added in anyway.
Member
Set<Network> attachedNetworks;
如果我不需要这是双向的(例如,我只需要从网络访问成员,不需要能够以其他方式旅行),对我来说最明显的解决方案是每组成员(network_member、suppressed_member、added_member
)都有一个链接表,但反之就会崩溃。我想我可以使用单个链接表并将其转换为带有鉴别器列的实体,但每次我看到有人使用链接表作为实体时,代码似乎都会变成一场灾难。
我发现了很多类似的问题,但这些问题要么有点太具体,要么答案没有完全涵盖我正在寻求的解决方案。关于处理这种情况的最佳方法有什么建议吗?
My basic scenario is a bi-directional many-to-many relationship that is being mapped with JPA. Simple enough. However, I need to add a 'type' to the mapping, and I'm struggling with the best implementation. Here's the outline:
Network
Set<Member> defaultMembers; //members that meet the network definition
Set<Member> suppressedMembers; //members that meet the network definition, but are hidden.
Set<Member> addedMembers; //memders that don't meet the network definition, but have been added in anyway.
Member
Set<Network> attachedNetworks;
If I didn't need this to be bi-directional (e.g., I only needed to get to members from networks and didn't need to be able to travel the other way), the most obvious solution to me is one link table for each set of members (network_member, suppressed_member, added_member
), but that falls apart going the other way. I suppose I could use a single link table and turn it into an entity with a discriminator column, but every time I've seen someone use a link table as an entity the code seems to turn into a disaster.
I've found many similar questions, but the questions have either been a little too specific, or the answers haven't quite covered the solution I'm seeking. Any suggestions on the best way to handle this situation?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
显而易见的、可移植的解决方案如下:
Attachment
实体,具有一个成员、一个网络和一种类型附件(默认、抑制或添加)。在网络和附件之间有一个一对多双向关联,在成员和附件之间有另一个一对多双向关联。如果不适合,请解释原因。
The obvious, portable solutions are the following ones:
Attachment
entity, having a member, a network, and a type of attachment (default, suppressed or added). Have a OneToMany bidirectional association between Network and Attachment, and another OneToMany bidirectional associatio between Member and Attachment.If they don't fit, please explain why.