On 9/7/2011 6:30 AM, Gordon Yorke wrote:
> Inline:
> --Gordon
>
> On 9/6/2011 6:07 PM, Linda DeMichiel wrote:
>> Rainer, thanks for weighing in on this issue.
>>
>> Do any of the rest of you have an opinion on this item? I'd like
>> to add a clarification one way or the other (as suggested below).
>>
>> thanks,
>>
>> -Linda
>>
>>
>> On 9/5/2011 8:20 AM, Rainer Kwesi Schweigkoffer wrote:
>>> Hi Emmanuel, all,
>>>
>>> Emmanuel Bernard, am 2 Sep 2011 hast Du um 10:51 zum Thema "[jsr338-experts] @OneToOne(optional=true) and @Pr"
>>> geschrieben :
>>>
>>>> @Entity
>>>> class User {
>>>> @Id String username;
>>>>
>>>> @OneToOne(optional=true) @PrimaryKeyJoinColumn
>>>> Profile getProfile() { ... };
>>>> }
>>>
>>>> But elsewhere the spec mention the need to have foreign keys (in general).
>>>
>>> I'd favour to explicitly state that in the above case that no foreign
>>> key is created, but could also live with a statement that the
>>> combination of optional=true and @PrimaryKeyJoinColumn is not portably
>>> supported.
> In this case a Foreign Key Constraint on the primary key column(s) would be unexpected. In general I do not believe the
> specification requires creation of foreign key constraints at all. The only section that mentions foreign key
> constraints rather ambiguously refers to Providers maintaining referential integrity as declared within the database by
> such mechanisms as foreign key constraints.
Right. However, SQL (i.e., the "standard") does define "foreign key" in terms of FK constraints,
so depending on where one is coming from that might be a logical reference to make.
In any event, I'm inclined to address this particular item with a note in section 11.1.40 to the
effect that "It is not expected that a database foreign key be defined for the OneToOne mapping,
as the OneToOne relationship may be defined as "optional=true".
Please let me know if any of you disagree.
thanks,
-Linda
>>>
>>> In the derived entity case the relationship becomes part of the id and,
>>> hence, to my understanding may not be null.
> Agreed, derived ids are a special case with additional restrictions that are clearly specified in the specification
> (Section 2.4.1).
>>>
>>> With respect to
>>> http://lists.jboss.org/pipermail/hibernate-dev/2011-August/006980.html
>>> I have not fully understood the distinction between generated and user-
>>> defined ids. Why would the fact that a user id was generated require
>>> the user to have a profile ?
>>>
>>> Kind regards
>>> Rainer
>>>
>>>
>>>
>>>
>>> ---
>>> Rainer Schweigkoffer SAP AG Walldorf
>>> Business Solution& Technology TD Core JS&I
>>> Technology Development Dietmar-Hopp-Allee 16
>>> Java Server Core D-69190 Walldorf
>>> JEE Implementation Group phone: +49 6227 7 45305
>>> Building 3, I.3.14 fax: +49 6227 7 821177
>>> rainer.schweigkoffer_at_sap.com
>>>
>>> Sitz der Gesellschaft/Registered Office: Walldorf, Germany
>>> Vorstand/SAP Executive Board: Werner Brandt, Angelika Dammann,
>>> Bill McDermott (Co-CEO), Gerhard Oswald, Vishal Sikka,
>>> Jim Hagemann Snabe (Co-CEO)
>>> Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory
>>> Board: Hasso Plattner
>>> Registergericht/Commercial Register Mannheim No HRB 350269
>>>
>>> Diese E-Mail kann Betriebs- oder Geschaeftsgeheimnisse oder sonstige
>>> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail
>>> irrtuemlich erhalten haben, ist Ihnen eine Verwertung des Inhalts,
>>> eine Vervielfaeltigung oder Weitergabe der E-Mail ausdruecklich
>>> untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die
>>> empfangene E-Mail. Vielen Dank.
>>>
>>> This e-mail may contain trade secrets or privileged, undisclosed, or
>>> otherwise confidential information. If you have received this e-mail
>>> in error, you are hereby notified that any review, copying, or
>>> distribution of it is strictly prohibited. Please inform us
>>> immediately and destroy the original transmittal. Thank you for your
>>> cooperation.
>>>