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 <steve(a)hibernate.org&gt; Sent: ‎10/‎24/‎2016 22:21 To: hibernate-dev <hibernate-dev(a)lists.jboss.org&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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 <steve(a)hibernate.org&gt; 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.vlad(a)gmail.com&gt; > 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 <steve(a)hibernate.org&gt; >> Sent: ‎10/‎24/‎2016 22:21 >> To: hibernate-dev <hibernate-dev(a)lists.jboss.org&gt; >> 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

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 <sanne(a)hibernate.org&gt; 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 <steve(a)hibernate.org&gt; 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.vlad(a)gmail.com&gt; > > 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 <steve(a)hibernate.org&gt; > >> Sent: ‎10/‎24/‎2016 22:21 > >> To: hibernate-dev <hibernate-dev(a)lists.jboss.org&gt; > >> 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(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev

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 <sanne(a)hibernate.org&gt; wrote: On 24 October 2016 at 21:49, Steve Ebersole <steve(a)hibernate.org&gt; 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 <sanne(a)hibernate.org&gt; 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 <steve(a)hibernate.org&gt; 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.vlad(a)gmail.com&gt; >> > 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 <steve(a)hibernate.org&gt; >> >> Sent: ‎10/‎24/‎2016 22:21 >> >> To: hibernate-dev <hibernate-dev(a)lists.jboss.org&gt; >> >> 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(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev