In org.hibernate.test.annotations.derivedidentities.e4.a
The main entity (Person) has an id of type String
The derived entity (MedicalHistory) has an id of type
The TCK expects to be able to do
em.find(MedicalHistory.class, "ssn");
but we do map MedicalHistory id as a core-stype embedded id so the PK is MedicalHistory
Well the assumption being made here is that you can directly look things up based on the underlying (aka db) PK type. I mean even if this were not handled as an embedded component, why would the id type not logically be a Person?
Think of it like this, if you had a composite id (@EmbeddedId), is it valid to say:
em.find( MyEntity.class, new Object[] { componentSub1, componentSub2, ... } );
If the spec says (not the tck says) we have to support it we'll have to support it...
I think you have a point, Person should really be the type.
That being said, the derived identity takes a different approach in which the java type of the associated entity is considered the or part of the pk
section 2.4.1.1 sums it up. Here is an extract for "simple pks".
If the dependent entity has a single primary key attribute (i.e, the relationship attribute or an attribute that corresponds to the relationship attribute) and the primary key of the parent entity is a simple pri- mary key, the primary key of the dependent entity is a simple primary key of the same type as that of the parententity(andneitherEmbeddedIdnorIdClassisspecified). Inthiscase,either(1)therela- tionship attribute is annotated Id, or (2) a separate Id attribute is specified and the relationship attribute is annotated MapsId (and the value element of the MapsId annotation is not specified).