Historically (well before JPA) HIbernate would handle dynamic instantiation queries in cases where one of the arguments is an entity-reference by passing just the entity's identifier rather than a complete reference to the entity. To be clear, I am talking about a query like:
select new DTO( p ) from Person p
Hibernate implicitly treats this like:
select new DTO( p.id ) from Person p
and expects DTO to have a ctor taking the appropriate ID type.
E.g., assuming a Person:
{code}
@Entity
class Person {
@Id
Long id;
...
}
{code}
and given a query like:
{code}
select new DTO( p ) from Person p
{code}
Hibernate would expect DTO to be defined as (specifically the ctor):
{code}
class DTO {
public DTO(Long id) {...}
...
}
{code}
DTO could *also* define a ctor taking Person as the arg, Hibernate would just not never use that form.
Along comes JPA and also defines support for dynamic instantiation queries, but does not specify one way or the other how this case should be handled. I have been told other providers interpret this the opposite way. Makes sense. I think it is time we at least allow that as an option. Or maybe a nicer implementation that looks for both and picks the available one (if that's not too much effort).
The proposal is proposing was for adding some support for this in 6.0 based on the SQM work where we can either:
# add a flag that says whether to support legacy behavior, or this new behavior
# attempt to dynamically infer what to do based on available ctors
(2) would be awesome I think. We'd still have to know how to handle cases where the DTO defined ctors matching both cases and which to prefer. |
|
