>
> Maybe you're right but I don't have the same rightness feeling.
>
> Anyways, we can't rewrite history and we can differentiate not set
> from set to a value in Java's annotations. Besides, I suspect (has to
> be verified) that normal forms don't like null values even for foreign
> keys. This approach could be considered better though the proper
> approach would be to use a join table with unique constraints.
By "normal form" do you mean @OneToOne(optional=true) without a
@PrimaryKeyJoinColumn or derived ID? If so, this case works fine; the foreign key column
is nullable and the foreign key constraint is exported.
No, I mean
http://en.wikipedia.org/wiki/Normal_form
>
>> Implicitly applying @NotFound(IGNORE) would break the default
>> mappings for unidirectional and bidirectional one-to-one
>> relationships documented in the spec.
>
> Can you expand here. I don't follow you.
>
In 2.10.1 Bidirectional OneToOne Relationships:
The following mapping defaults apply:
Entity A is mapped to a table named A.
Entity B is mapped to a table named B.
Table A contains a foreign key to table B. The foreign key column name is formed as the
con-
catenation of the following: the name of the relationship property or field of entity A;
"_"; the
name of the primary key column in table B. The foreign key column has the same type as
the
primary key of table B and there is a unique key constraint on it.
In 2.10.3.1 Unidirectional OneToOne Relationships:
The following mapping defaults apply:
Entity A is mapped to a table named A.
Entity B is mapped to a table named B.
Table A contains a foreign key to table B. The foreign key column name is formed as the
con-
catenation of the following: the name of the relationship property or field of entity A;
"_"; the
name of the primary key column in table B. The foreign key column has the same type as
the
primary key of table B and there is a unique key constraint on it.
These are for the default case which we are not in as @PrimaryKeyJoinColumn is used. But I
see your point. Note that the spec seems inconsistent if we want to both support
optional=true and some foreign key constraint generation. We have to chose what's best
of a user rather than rely on some elements of the spec.
I have emailed Linda to see what she thinks.