[hibernate-dev] dynamic instantiation queries
Historically (well before JPA) HIbernate would handle dynamic instantiation queries in cases where one of the arguments being 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. JPA came along 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). What do y'all think? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] dynamic instantiation queries
Do you mean we should allow the dynamic instantiation to resolve entities when we pass the entity identifier? I think I saw this request on StackOverflow once. Did I understand the question properly? Vlad -Original Message- From: "Steve Ebersole" Sent: 10/24/2016 22:21 To: "hibernate-dev" Subject: [hibernate-dev] dynamic instantiation queries Historically (well before JPA) HIbernate would handle dynamic instantiation queries in cases where one of the arguments being 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. JPA came along 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). What do y'all think? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] dynamic instantiation queries
So Person is your entity, e.g.:
@Entity
class Person {
@Id
Long id;
...
}
For a query like `select new DTO( p ) from Person p` Hibernate expects a
DTO like:
class DTO {
public DTO(Long id) {
...
}
}
in fact a DTO like:
class DTO {
public DTO(Person person) {
...
}
}
will not work with Hibernate.
What I was proposing was for adding some support for that in 6.0 based on
the SQM work. "Support" here could mean either:
1) add a flag that says whether to support legacy behavior, or this new
behavior
2) attempt to dynamically infer what to do (looks at 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.
On Mon, Oct 24, 2016 at 2:31 PM Vlad Mihalcea
wrote:
> Do you mean we should allow the dynamic instantiation to resolve entities
> when we pass the entity identifier?
>
> I think I saw this request on StackOverflow once.
>
> Did I understand the question properly?
>
> Vlad
> --
> From: Steve Ebersole
> Sent: 10/24/2016 22:21
> To: hibernate-dev
> Subject: [hibernate-dev] dynamic instantiation queries
>
> Historically (well before JPA) HIbernate would handle dynamic instantiation
> queries in cases where one of the arguments being 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.
>
> JPA came along 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).
>
> What do y'all think?
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 6.0 - Type redesign
2016-10-20 21:27 GMT+03:00 Steve Ebersole : > >> A type should be able to define classes Interfaces and Abstract >> classes that it can handle in their Java types. >> This will enable implementing handlers for things like javax.script.* >> objects that can have different providers, thus different class names >> of the final object. >> That would have to be a secondary check if no match is found by Java >> class name, because it's slower and dangerous when binding >> parameters to a query. > > > I am not sure what you are talking about here. > > >> If stored as Class object references, they would have to be held in >> WeakReference objects tied to a ReferenceQueue, so as not to >> prevent garbage collection when a context is unloaded in a multi-context >> server. >> >> If stored as Strings, there would have to be a call to Class.forName >> for each, which if successful would have to check isInstance on the >> object or isAssignableFrom on it's class (when evaluating DB model). > > > Again, not really sure what you are talking about here. I guess you mean in > some "cache" based on the Java type handled? > I am talking about type registration and resolution in both. Right now, they're being registered in org.hibernate.boot.model.process.spi.MetadataBuildingProcess#handleTypes which creates a BasicTypeRegistry for resolving them. In the current state, they can only be registered by full class name. I'm proposing that they can optionally register interfaces. > Statement also gives you access to the Connection (Statement#getConnection) > Which JavaTypeDescriptor wrap and unwrap have no access to under the old model. > In general a lot of points are just out of date. If you want to influence > the development of this or be part of it you should consider joining the > HipChat channel where we discuss this stuff. I stopped trying to discuss > here because no one generally answers. > By HipChat do you mean the IRC #hibernate channel on Freenode? If not, the Community page has no mention of HipChat. Time zone differences would likely make that a poor choice for me. I'm in the EET zone. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] dynamic instantiation queries
Option 2# looks very nice indeed, I'd like that as it would be useful
to be able to create immutable DTOs directly from a query; but I'm
wondering what kind of difficulties this might pose, for example I'd
assume the DTO constructor would be able to trigger lazy loading of
any property of Person?
Also wondering, if we expose query results as streams in the future,
would such a feature not become obsolete?
On 24 October 2016 at 20:38, Steve Ebersole wrote:
> So Person is your entity, e.g.:
>
> @Entity
> class Person {
> @Id
> Long id;
> ...
> }
>
> For a query like `select new DTO( p ) from Person p` Hibernate expects a
> DTO like:
>
> class DTO {
> public DTO(Long id) {
> ...
> }
> }
>
> in fact a DTO like:
>
> class DTO {
> public DTO(Person person) {
> ...
> }
> }
>
> will not work with Hibernate.
>
> What I was proposing was for adding some support for that in 6.0 based on
> the SQM work. "Support" here could mean either:
> 1) add a flag that says whether to support legacy behavior, or this new
> behavior
> 2) attempt to dynamically infer what to do (looks at 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.
>
>
> On Mon, Oct 24, 2016 at 2:31 PM Vlad Mihalcea
> wrote:
>
>> Do you mean we should allow the dynamic instantiation to resolve entities
>> when we pass the entity identifier?
>>
>> I think I saw this request on StackOverflow once.
>>
>> Did I understand the question properly?
>>
>> Vlad
>> --
>> From: Steve Ebersole
>> Sent: 10/24/2016 22:21
>> To: hibernate-dev
>> Subject: [hibernate-dev] dynamic instantiation queries
>>
>> Historically (well before JPA) HIbernate would handle dynamic instantiation
>> queries in cases where one of the arguments being 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.
>>
>> JPA came along 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).
>>
>> What do y'all think?
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] dynamic instantiation queries
I'm not sure what you are getting at. This is a feature Hibernate has had
for close to 15 years. It's not a "new feature", I'm just proposing a new
behavior to be more consistent with what people generally expect.
On Mon, Oct 24, 2016, 3:30 PM Sanne Grinovero wrote:
> Option 2# looks very nice indeed, I'd like that as it would be useful
> to be able to create immutable DTOs directly from a query; but I'm
> wondering what kind of difficulties this might pose, for example I'd
> assume the DTO constructor would be able to trigger lazy loading of
> any property of Person?
>
> Also wondering, if we expose query results as streams in the future,
> would such a feature not become obsolete?
>
>
> On 24 October 2016 at 20:38, Steve Ebersole wrote:
> > So Person is your entity, e.g.:
> >
> > @Entity
> > class Person {
> > @Id
> > Long id;
> > ...
> > }
> >
> > For a query like `select new DTO( p ) from Person p` Hibernate expects a
> > DTO like:
> >
> > class DTO {
> > public DTO(Long id) {
> > ...
> > }
> > }
> >
> > in fact a DTO like:
> >
> > class DTO {
> > public DTO(Person person) {
> > ...
> > }
> > }
> >
> > will not work with Hibernate.
> >
> > What I was proposing was for adding some support for that in 6.0 based on
> > the SQM work. "Support" here could mean either:
> > 1) add a flag that says whether to support legacy behavior, or this new
> > behavior
> > 2) attempt to dynamically infer what to do (looks at 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.
> >
> >
> > On Mon, Oct 24, 2016 at 2:31 PM Vlad Mihalcea
> > wrote:
> >
> >> Do you mean we should allow the dynamic instantiation to resolve
> entities
> >> when we pass the entity identifier?
> >>
> >> I think I saw this request on StackOverflow once.
> >>
> >> Did I understand the question properly?
> >>
> >> Vlad
> >> --
> >> From: Steve Ebersole
> >> Sent: 10/24/2016 22:21
> >> To: hibernate-dev
> >> Subject: [hibernate-dev] dynamic instantiation queries
> >>
> >> Historically (well before JPA) HIbernate would handle dynamic
> instantiation
> >> queries in cases where one of the arguments being 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.
> >>
> >> JPA came along 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).
> >>
> >> What do y'all think?
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] dynamic instantiation queries
I think attempting to dynamically infer what to do using the existing ctr
would be great
On 24 October 2016 at 21:49, Steve Ebersole wrote:
> I'm not sure what you are getting at. This is a feature Hibernate has had
> for close to 15 years. It's not a "new feature", I'm just proposing a new
> behavior to be more consistent with what people generally expect.
>
> On Mon, Oct 24, 2016, 3:30 PM Sanne Grinovero wrote:
>
> > Option 2# looks very nice indeed, I'd like that as it would be useful
> > to be able to create immutable DTOs directly from a query; but I'm
> > wondering what kind of difficulties this might pose, for example I'd
> > assume the DTO constructor would be able to trigger lazy loading of
> > any property of Person?
> >
> > Also wondering, if we expose query results as streams in the future,
> > would such a feature not become obsolete?
> >
> >
> > On 24 October 2016 at 20:38, Steve Ebersole wrote:
> > > So Person is your entity, e.g.:
> > >
> > > @Entity
> > > class Person {
> > > @Id
> > > Long id;
> > > ...
> > > }
> > >
> > > For a query like `select new DTO( p ) from Person p` Hibernate expects
> a
> > > DTO like:
> > >
> > > class DTO {
> > > public DTO(Long id) {
> > > ...
> > > }
> > > }
> > >
> > > in fact a DTO like:
> > >
> > > class DTO {
> > > public DTO(Person person) {
> > > ...
> > > }
> > > }
> > >
> > > will not work with Hibernate.
> > >
> > > What I was proposing was for adding some support for that in 6.0 based
> on
> > > the SQM work. "Support" here could mean either:
> > > 1) add a flag that says whether to support legacy behavior, or this new
> > > behavior
> > > 2) attempt to dynamically infer what to do (looks at 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.
> > >
> > >
> > > On Mon, Oct 24, 2016 at 2:31 PM Vlad Mihalcea >
> > > wrote:
> > >
> > >> Do you mean we should allow the dynamic instantiation to resolve
> > entities
> > >> when we pass the entity identifier?
> > >>
> > >> I think I saw this request on StackOverflow once.
> > >>
> > >> Did I understand the question properly?
> > >>
> > >> Vlad
> > >> --
> > >> From: Steve Ebersole
> > >> Sent: 10/24/2016 22:21
> > >> To: hibernate-dev
> > >> Subject: [hibernate-dev] dynamic instantiation queries
> > >>
> > >> Historically (well before JPA) HIbernate would handle dynamic
> > instantiation
> > >> queries in cases where one of the arguments being 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.
> > >>
> > >> JPA came along 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).
> > >>
> > >> What do y'all think?
> > >> ___
> > >> hibernate-dev mailing list
> > >> hibernate-dev@lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] dynamic instantiation queries
On 24 October 2016 at 21:49, Steve Ebersole wrote:
> I'm not sure what you are getting at. This is a feature Hibernate has had
> for close to 15 years. It's not a "new feature", I'm just proposing a new
> behavior to be more consistent with what people generally expect.
Yes I like the proposal; I'm just wondering if there might be some
hidden complexities in allowing to initialise additional lazy
properties during the query execution, as a side-effect of the
constructor's code as I guess it might want to invoke various getters
on the Person instance. If you say that's not a problem, then that's
good news :)
>
>
> On Mon, Oct 24, 2016, 3:30 PM Sanne Grinovero wrote:
>>
>> Option 2# looks very nice indeed, I'd like that as it would be useful
>> to be able to create immutable DTOs directly from a query; but I'm
>> wondering what kind of difficulties this might pose, for example I'd
>> assume the DTO constructor would be able to trigger lazy loading of
>> any property of Person?
>>
>> Also wondering, if we expose query results as streams in the future,
>> would such a feature not become obsolete?
>>
>>
>> On 24 October 2016 at 20:38, Steve Ebersole wrote:
>> > So Person is your entity, e.g.:
>> >
>> > @Entity
>> > class Person {
>> > @Id
>> > Long id;
>> > ...
>> > }
>> >
>> > For a query like `select new DTO( p ) from Person p` Hibernate expects a
>> > DTO like:
>> >
>> > class DTO {
>> > public DTO(Long id) {
>> > ...
>> > }
>> > }
>> >
>> > in fact a DTO like:
>> >
>> > class DTO {
>> > public DTO(Person person) {
>> > ...
>> > }
>> > }
>> >
>> > will not work with Hibernate.
>> >
>> > What I was proposing was for adding some support for that in 6.0 based
>> > on
>> > the SQM work. "Support" here could mean either:
>> > 1) add a flag that says whether to support legacy behavior, or this new
>> > behavior
>> > 2) attempt to dynamically infer what to do (looks at 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.
>> >
>> >
>> > On Mon, Oct 24, 2016 at 2:31 PM Vlad Mihalcea
>> > wrote:
>> >
>> >> Do you mean we should allow the dynamic instantiation to resolve
>> >> entities
>> >> when we pass the entity identifier?
>> >>
>> >> I think I saw this request on StackOverflow once.
>> >>
>> >> Did I understand the question properly?
>> >>
>> >> Vlad
>> >> --
>> >> From: Steve Ebersole
>> >> Sent: 10/24/2016 22:21
>> >> To: hibernate-dev
>> >> Subject: [hibernate-dev] dynamic instantiation queries
>> >>
>> >> Historically (well before JPA) HIbernate would handle dynamic
>> >> instantiation
>> >> queries in cases where one of the arguments being 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.
>> >>
>> >> JPA came along 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).
>> >>
>> >> What do y'all think?
>> >> ___
>> >> hibernate-dev mailing list
>> >> hibernate-dev@lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] dynamic instantiation queries
Still not really understanding what you are getting at. Do you have an
example?
The entity passed into the "DTO" would be managed. If they wanted to
initialize stuff on that entity it would happen just as normal for a
managed entity. Is that what you mean?
On Mon, Oct 24, 2016, 4:34 PM Sanne Grinovero wrote:
> On 24 October 2016 at 21:49, Steve Ebersole wrote:
> > I'm not sure what you are getting at. This is a feature Hibernate has had
> > for close to 15 years. It's not a "new feature", I'm just proposing a
> new
> > behavior to be more consistent with what people generally expect.
>
> Yes I like the proposal; I'm just wondering if there might be some
> hidden complexities in allowing to initialise additional lazy
> properties during the query execution, as a side-effect of the
> constructor's code as I guess it might want to invoke various getters
> on the Person instance. If you say that's not a problem, then that's
> good news :)
>
> >
> >
> > On Mon, Oct 24, 2016, 3:30 PM Sanne Grinovero
> wrote:
> >>
> >> Option 2# looks very nice indeed, I'd like that as it would be useful
> >> to be able to create immutable DTOs directly from a query; but I'm
> >> wondering what kind of difficulties this might pose, for example I'd
> >> assume the DTO constructor would be able to trigger lazy loading of
> >> any property of Person?
> >>
> >> Also wondering, if we expose query results as streams in the future,
> >> would such a feature not become obsolete?
> >>
> >>
> >> On 24 October 2016 at 20:38, Steve Ebersole
> wrote:
> >> > So Person is your entity, e.g.:
> >> >
> >> > @Entity
> >> > class Person {
> >> > @Id
> >> > Long id;
> >> > ...
> >> > }
> >> >
> >> > For a query like `select new DTO( p ) from Person p` Hibernate
> expects a
> >> > DTO like:
> >> >
> >> > class DTO {
> >> > public DTO(Long id) {
> >> > ...
> >> > }
> >> > }
> >> >
> >> > in fact a DTO like:
> >> >
> >> > class DTO {
> >> > public DTO(Person person) {
> >> > ...
> >> > }
> >> > }
> >> >
> >> > will not work with Hibernate.
> >> >
> >> > What I was proposing was for adding some support for that in 6.0 based
> >> > on
> >> > the SQM work. "Support" here could mean either:
> >> > 1) add a flag that says whether to support legacy behavior, or this
> new
> >> > behavior
> >> > 2) attempt to dynamically infer what to do (looks at 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.
> >> >
> >> >
> >> > On Mon, Oct 24, 2016 at 2:31 PM Vlad Mihalcea <
> mihalcea.v...@gmail.com>
> >> > wrote:
> >> >
> >> >> Do you mean we should allow the dynamic instantiation to resolve
> >> >> entities
> >> >> when we pass the entity identifier?
> >> >>
> >> >> I think I saw this request on StackOverflow once.
> >> >>
> >> >> Did I understand the question properly?
> >> >>
> >> >> Vlad
> >> >> --
> >> >> From: Steve Ebersole
> >> >> Sent: 10/24/2016 22:21
> >> >> To: hibernate-dev
> >> >> Subject: [hibernate-dev] dynamic instantiation queries
> >> >>
> >> >> Historically (well before JPA) HIbernate would handle dynamic
> >> >> instantiation
> >> >> queries in cases where one of the arguments being 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.
> >> >>
> >> >> JPA came along 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).
> >> >>
> >> >> What do y'all think?
> >> >> ___
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev@lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >>
> >> > ___
> >> > hibernate-dev mailing list
> >> > hibernate-dev@lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
