The fix for HHH- 10556 5948 changed the collection role to be constructed using the entity that is the path source instead of the entity that declares the collection.
For example, here is a simplified version of the test added for HHH-10556, [SuperclassCollectionTest|https://github.com/hibernate/hibernate-orm/blob/master/hibernate-entitymanager/src/test/java/org/hibernate/jpa/test/criteria/SuperclassCollectionTest.java]:
{{
@MappedSuperclass
public class PersonBase {
@Id @GeneratedValue
Integer id;
@OneToMany(cascade = CascadeType.ALL)
List<Address> addresses = new ArrayList<Address>();
}
@Entity
public class Person extends PersonBase {
...
}
}}
In the following {{CriteriaQuery}}:
{{
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Object> cq = cb.createQuery();
Root<?> root = cq.from( Person.class );
cq.select( root.get( "addresses" ) )...
}}
the collection role constructed for {{Person.addresses}} is "...Person.addresses", even though {{addresses}} is declared in {{PersonBase}}. I believe this is only correct in this case because {{PersonBase}} is a mappedsuperclass. IIRC, the role for a collection in a mappedsuperclass is considered to be in subclasses marked {@Entity} that extend a mappedsuperclass.
If another subclass is added:
{{
@Entity
public class OtherPerson extends Person {
}
}}
and the {{CriteriaQuery}} is changed to:
{{
...
Root<?> root = cq.from( OtherPerson.class );
cq.select( root.get( "addresses" ) )...
}}
the collection role constructed for {{OtherPerson.addresses}} is "...OtherPerson.addresses", which causes the {{CriteriaQuery}} to fail because there is no such collection role. The constructed collection role should be "..Person.addresses" as well. |
|