On 24 October 2016 at 21:49, Steve Ebersole <st...@hibernate.org> 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 <sa...@hibernate.org> 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 <st...@hibernate.org> 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 <st...@hibernate.org>
>> >> Sent: 10/24/2016 22:21
>> >> To: hibernate-dev <hibernate-dev@lists.jboss.org>
>> >> 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
