@JoinColumn
和@PrimaryKeyJoinColumn
之间的确切区别是什么?
对于属于外键的列,您使用@JoinColumn
。典型的列可能看起来像(例如在具有其他属性的连接表中):
@ManyToOne
@JoinColumn(name = "...")
private OtherClass oc;
如果我将列提升为/ PK(a.k.a.识别关系)会怎样?由于该列现在是PK,我必须使用@Id
标记它:
@Id
@ManyToOne
@JoinColumn(name = "...")
private OtherClass oc;
现在的问题是:
@Id
+ @JoinColumn
是否与@PrimaryKeyJoinColumn
相同?:
@ManyToOne
@PrimaryKeyJoinColumn(name = "...")
private OtherClass oc;
如果没有,那里的@PrimaryKeyJoinColumn
是什么?
答案 0 :(得分:49)
如果我将列提升为/ PK(a.k.a.识别关系)会怎样?由于该列现在是PK,我必须用@Id(...)标记它。
派生标识符的这种增强支持实际上是new stuff in JPA 2.0的一部分(请参阅JPA 2.0中 2.4.1对应于派生身份的主键部分)规范),JPA 1.0不允许在Id
或OneToOne
上使用ManyToOne
。使用JPA 1.0,您必须使用PrimaryKeyJoinColumn
并为外键列定义Basic
Id
映射。
现在的问题是:@Id + @JoinColumn和@PrimaryKeyJoinColumn一样吗?
您可以获得类似的结果,但在Id
上使用OneToOne
或ManyToOne
更简单,并且是使用JPA映射派生标识符的首选方式2.0。 PrimaryKeyJoinColumn
可能仍会在 JOINED 继承策略中使用。在JPA 2.0规范的相关部分下面:
11.1.40 PrimaryKeyJoinColumn Annotation
PrimaryKeyJoinColumn
注释 指定一个主键列 用作加入的外键 另一张桌子。
PrimaryKeyJoinColumn
注释 用于连接主表JOINED
中的实体子类 将策略映射到主表 其超类;它用在一个 要加入的SecondaryTable
注释 辅助表到主表; 它可以在OneToOne
中使用 映射中的主键 引用实体用作 引用的外键 实体 [108]...
如果没有
PrimaryKeyJoinColumn
为子类指定注释 在JOINED映射策略中, 假定使用外键列 与主键名称相同 主表的列 超类。...
示例: Customer和ValuedCustomer子类
@Entity @Table(name="CUST") @Inheritance(strategy=JOINED) @DiscriminatorValue("CUST") public class Customer { ... } @Entity @Table(name="VCUST") @DiscriminatorValue("VCUST") @PrimaryKeyJoinColumn(name="CUST_ID") public class ValuedCustomer extends Customer { ... }
[108] 派生的id机制 现在是2.4.1.1节中描述的 优先于
PrimaryKeyJoinColumn
为 OneToOne映射案例。
此来源http://weblogs.java.net/blog/felipegaucho/archive/2009/10/24/jpa-join-table-additional-state声明使用@ManyToOne和@Id适用于JPA 1.x.谁现在正确?
作者正在使用预发布的 JPA 2.0 兼容的EclipseLink版本(文章发布时为2.0.0-M7)来撰写有关JPA 1.0(!)的文章。本文具有误导性,作者使用的是 NOT JPA 1.0的一部分。
为了记录,EclipseLink 1.1中添加了对Id
和OneToOne
的{{1}}的支持(请参阅this message的James Sutherland,EclipseLink comitter和main Java Persistence维基书的撰稿人。但是让我坚持,这是JPA 1.0的 NOT 部分。
答案 1 :(得分:21)
答案 2 :(得分:2)
我知道这是一篇过时的文章,但是使用PrimaryKeyColumn
的好时机将是您是否需要单向关系或有多个共享相同ID的表。
通常,这不是一个好主意,最好将外键关系与JoinColumn
一起使用。
话虽如此,如果您正在使用这样的系统的旧数据库上工作,那将是使用它的好时机。