>> >> 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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
