After weighing the options here, I've concluded that to accommodate
the ability to specify composite foreign keys, we should add a
ForeignKey element to the CollectionTable, SecondaryTable, and
AssociationOverride annotations, and a pair of ForeignKey elements to
the JoinTable annotation.
If both such a ForeignKey element and the foreignKey element within the
JoinColumn element are specified in one of these annotations, the
behavior would be undefined.
I also think that we need to make more intuitive what specifying
@ForeignKey() as a value of such an element means--i.e., specifying
@ForeignKey() when all of its member values are defaulted-- since the
user's expectation will probably be that this means that foreign key
constraints will be generated when schema generation is in effect. To
clarify this, we should replace the current disableForeignKey with a
3-valued enum (PROVIDER_DEFAULT, CONSTRAINT, NO_CONSTRAINT). By
default, if @ForeignKey is not specified, the default provider
behavior will apply and @ForeignKey() will be equivalent to
@ForeignKey(CONSTRAINT).
I've uploaded javadocs that capture all of this.
(
http://java.net/projects/jpa-spec/downloads/download/JPAjavadocs02142013.zip)
See especially the following: ForeignKey, ConstraintMode, JoinColumn,
JoinTable, CollectionTable, SecondaryTable.
Please let me know if you find anything amiss.
thanks,
-Linda
On 2/11/2013 11:48 AM, Linda DeMichiel wrote:
> Here's my assessment of the issue.
>
> Ideally, I think foreign-key metadata should be kept in the
> JoinColumn(s) annotations. However, for compound primary keys
> we have JoinColumn[] elements (or related elements) in the
> JoinTable, CollectionTable, and SecondaryTable annotations, which
> do not support this cleanly.
>
> I see several options (none unfortunately ideal):
>
> 1) Move @ForeignKey to top level. I think this gets messy because
> it allows for a lot of overlap in where it might be specified.
>
> 2) Add @ForeignKey elements to JoinTable, CollectionTable, and SecondaryTable
> and clarify that they are to be used for compound FKs.
>
> 3) Clarify that for compound foreign keys, in JoinTable, CollectionTable,
> and SecondaryTable that at most one of the joinColumn elements should
> be used to hold the FK metadata for the compound FK.
>
> Am I missing anything?
>
> Do any of you see a better way?
>
> So far, I am leaning toward #3 as the least objectionable.
>
> Opinions??
>
> thanks,
>
> -Linda
>
>
>
>
> On 2/8/2013 9:33 AM, Linda DeMichiel wrote:
>> Sigh. This is a bug (and with the other @XXXTable mappings that allow joinColumns to be
>> specified). I intended compound FKs to be handled in @JoinColumns, but these mapping
>> types don't have a @JoinColumns subelement by rather a JoinColumn[] element.
>>
>> Will need to reevaluate.
>>
>> thanks,
>>
>> -Linda
>>
>>
>> On 2/8/2013 9:07 AM, Steve Ebersole wrote:
>>> There is a discrepency between orm.xsd and the spec. orm.xsd defines that join-table lists that foreign-key should be a
>>> sub-element, however @JoinTable does not define a foreignKeys attribute.
>>>
>>>
>>> On Tue 05 Feb 2013 06:48:12 PM CST, Linda DeMichiel wrote:
>>>>
>>>> I've posted a new spec draft with the updated schema generation metadata
>>>> to the project Downloads area. This draft also contains the updated
>>>> persistence and orm schemas. I have also uploaded these xsd files to
>>>> the Downloads area.
>>>>
>>>> Notice that the namespace in the schemas has changed, as we will no
>>>> longer
>>>> be using java.sun.com for new work. There are no other modifications to
>>>> the schema for the persistence.xml, but since we have changed the orm
>>>> schema,
>>>> I figured it would be less confusing if both xsd files were updated.
>>>>
>>>> -Linda