我的回答:以下所有内容都应该被覆盖(即在columndefinition
适当的情况下将它们全部描述在 内):
length
precision
scale
nullable
unique
即 DDL 列将包括:name
+columndefinition
而没有别的。
理由如下。
包含单词“Column”或“Table”的注释是纯粹的物理属性 -仅用于控制 DDL/DML 对数据库的属性。
其他纯逻辑注释 - 在 Java 中用于控制 JPA 处理的内存中的属性。
这就是为什么有时看起来可选性/可空性设置了两次——一次 via@Basic(...,optional=true)
和一次 via @Column(...,nullable=true)
。前者说,在刷新时,JPA 对象模型(内存中)中的属性/关联可以为空;后者说 DB 列可以为空。通常您希望它们设置相同 -但并非总是如此,这取决于数据库表的设置和重用方式。
在您的示例中,长度和可为空的属性被覆盖和冗余。
那么,在指定 columnDefinition 时,@Column 的其他哪些属性是多余的?
在 JPA 规范和 javadoc 中:
columnDefinition
定义:
为列生成 DDL 时使用的 SQL 片段。
columnDefinition
默认值:
生成的 SQL 以创建推断类型的列。
提供了以下示例:
@Column(name="DESC", columnDefinition="CLOB NOT NULL", table="EMP_DETAIL")
@Column(name="EMP_PIC", columnDefinition="BLOB NOT NULL")
而且,呃……,真的是这样。:-$ ?!
columnDefinition 是否会覆盖同一注释中提供的其他属性?
javadoc 和 JPA 规范没有明确解决这个问题——规范没有提供很好的保护。要 100% 确定,请使用您选择的实现进行测试。
JPA 规范中提供的示例可以安全地暗示以下内容
name
&table
可以与 结合使用columnDefinition
,两者都不会被覆盖
nullable
被覆盖/冗余columnDefinition
从“情况的逻辑”中可以相当安全地暗示以下内容(我刚刚说过吗?? :-P ):
length
, precision
,scale
被覆盖/冗余columnDefinition
- 它们是类型的组成部分
insertable
和updateable
单独提供并且从不包含在 中columnDefinition
,因为它们在内存中控制 SQL 生成,然后再将其发送到数据库。
只剩下 " unique
" 属性。它类似于 nullable - 扩展/限定类型定义,因此应该被视为类型定义的组成部分。即应该被覆盖。
分别对“A”和“B”列测试我的答案:
@Column(name="...", table="...", insertable=true, updateable=false,
columndefinition="NUMBER(5,2) NOT NULL UNIQUE"
@Column(name="...", table="...", insertable=false, updateable=true,
columndefinition="NVARCHAR2(100) NULL"
- 确认生成的表具有正确的类型/可空性/唯一性
- 可选地,进行 JPA 插入和更新:前者应包括 A 列,后者应包括 B 列