[hibernate-dev] On @OneToOne(optional=true) and @PrimaryKeyJoinColumn

[Emmanuel Bernard]

>> 
>> 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.