I think Michael was under the impression that the method extracts an id property from the Class given. If you only look at this method, you don't necessarily consider other potentially available methods. Plus, the Java reflection methods usually work directly on the object they are invoked on. The passing of a parameter can lead to the impression the parameter and only the parameter get inspected.
Anyway, does it hurt to add, that the parameter actually identifies a persistent entity or mapped superclass and the id detection will consider the entire tree?
Cheers,
Ollie
Am 23.07.2012 um 19:41 schrieb Linda DeMichiel:
>
>
> On 7/23/2012 9:58 AM, Matthew Adams wrote:
>> Ok, so from your answer, I take it that it is the implementation's responsibility to walk up the entity's metadata
>> hierarchy through any mapped superclasses until the class defining the identity is found.
>>
>> Is that specified? The spec currently says:
>>
>> /**
>> * Return the attribute that corresponds to the id attribute of
>> * the entity or mapped superclass.
>> * @param type the type of the represented id attribute
>> * @return id attribute
>> * @throws IllegalArgumentException if id attribute of the given
>> * type is not present in the identifiable type or if
>> * the identifiable type has an id class
>> */
>> <Y> SingularAttribute<? super X, Y> getId(Class<Y> type);
>>
>> Potential javadoc clarification:
>>
>> "Return the attribute that corresponds to the id attribute of the entity, mapped superclass, or the id of the entity's
>> or mapped superclasses' superclass(es). This method must not return null."
>>
>> Better? Is there a TCK test for this?
>>
>
> Not sure. I guess I don't understand the confusion, given that there is a getDeclaredId method.
>
> The method pairs getXXX, getDeclaredXXX mirror what java.lang.reflect does, so I really don't
> think this needs a change.
>
> Under what circumstances would you imagine that it would return null rather than throw an IAE?
>
> -Linda
>
> p.s. I'll let our TCK engineer respond to the test question.
>
>
>
>> -matthew
>>
>> On Mon, Jul 23, 2012 at 11:05 AM, Linda DeMichiel <linda.demichiel_at_oracle.com <mailto:linda.demichiel_at_oracle.com>> wrote:
>>
>> Hi Matthew,
>>
>>
>> On 7/23/2012 6:44 AM, Matthew Adams wrote:
>>
>> Hi all,
>>
>> Scenario: entity "app.domain.Profile" extends abstract mapped superclass "app.domain.AbstractEntity". If
>> AbstractEntity defines a single string field as its @Id, should the IdentifiableType instance corresponding to
>> app.domain.Profile guarantee that its getId(Class) method will never return null?
>>
>> In other words, is it up to the client of the JPA metamodel to go up the entity's type hierarchy until it finds the
>> SingularAttribute for the id field, or should the JPA implementation do that?
>>
>>
>> I'm not sure I understand your question fully. However, it is the responsibility of the metamodel implementation
>> to return the SingularAttribute that is the value of getId (this may involve traversing the hierarchy if getId
>> were not defined in the IdentifiablyType itself).
>>
>> -Linda
>>
>>
>> Thanks,
>> Matthew
>>
>> --
>> mailto:matthew_at_matthewadams.me <mailto:matthew_at_matthewadams.me>
>> skype:matthewadams12
>> googletalk:matthew@__matthewadams.me <mailto:googletalk%3Amatthew_at_matthewadams.me>
>> <mailto:googletalk%3Amatthew@__matthewadams.me <mailto:googletalk%253Amatthew_at_matthewadams.me>>
>> http://matthewadams.me
>> http://www.linkedin.com/in/__matthewadams <http://www.linkedin.com/in/matthewadams>
>>
>>
>>
>>
>> --
>> mailto:matthew_at_matthewadams.me
>> skype:matthewadams12
>> googletalk:matthew_at_matthewadams.me <mailto:googletalk%3Amatthew_at_matthewadams.me>
>> http://matthewadams.me
>> http://www.linkedin.com/in/matthewadams
>>
--
/**
* @author Oliver Gierke - Senior Member Technical Staff
*
* @param email ogierke_at_vmware.com
* @param phone +49-351-30929001
* @param fax +49-351-418898439
* @param skype einsdreizehn
* @see http://www.olivergierke.de
*/