Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Romain Manni-Bucau]

2017-05-04 19:28 GMT+02:00 Steve Ebersole :

> I should clarify... if your `serialzer#serialize` call is not
> "recursively" calling into this check then my example would not work; but
> then again, neither would yours
>

Well mine works (no "would" ;)) cause jsonb implements the visitor pattern
for me in my case.

But ok, let's see this Navigable solution when out, sounds promishing.


>
> On Thu, May 4, 2017, 12:26 PM Steve Ebersole  wrote:
>
>> Hibernate#isInitialized is an overloaded method.  I think you want to
>> look at the different forms.
>>
>> And yes, Navigable will define visitor-based navigation. Hence the name ;)
>>
>> On Thu, May 4, 2017, 12:18 PM Romain Manni-Bucau 
>> wrote:
>>
>>> 2017-05-04 19:16 GMT+02:00 Steve Ebersole :
>>>
 But your psuedo code is really just the same as:

 AnEntity e = find();
 if ( isInitialized( e ) ) {
 serializer.serialize(e);
 }

>>>
>>> no cause it is done in the graph visitor and not just the root, that's
>>> the key difference.
>>>
>>>

 boolean isInitialized(Object e) {
 return Hibernate.isInitialized( e );
 }

 What I was getting at with the 6.0 + Navigavble discussion is that it
 would be better to base this "isInitialized" on these Navigables instead.
 A Navigable is a polymorphic reference that might be an entity, a
 persistent attribute, a "collection element", etc.

>>>
>>> Would need to see it in a more concrete version but sounds tempting,
>>> would it integrate a visitor - handling cycles?
>>>
>>>


 On Thu, May 4, 2017 at 11:46 AM Romain Manni-Bucau <
 rmannibu...@gmail.com> wrote:

> 2017-05-04 18:42 GMT+02:00 Christian Beikov <
> christian.bei...@gmail.com>:
>
>> Detecting if an object is initialized should be as easy as calling "
>> Hibernate.isInitialized(object)". If you want to know whether a
>> specic attribute of an object is initialized you'd use 
>> "Hibernate.isPropertyInitialized(object,
>> attributeName)". What you want is some kind of integration that
>> makes use of these two methods, so that if they return false, a null 
>> value
>> is used when serializing objects to XML/JSON via JAXB/JSONB. Is that
>> correct?
>>
>
> Almost, I would like one able to just disable it, this way the
> serializer doesnt need anything or knowledge of hibernate. Worse case we
> need to integrate with the serializer in a way close to the one i proposed
> for johnzon before.
>
> In pseudo code it would be:
>
> AnEntity e = find();
> Hibernate.disableLazyExceptionWithNull(e);
> serializer.serialize(e);
>
>
>> I don't know of any hook in JAXB that could be used to put that code
>> into so it works out as you'd expect it. The only other way I can think 
>> of,
>> is nulling the properties explicitly which could be done quite easily. 
>> You
>> probably gonna need just a single recursive method to do that. I don't 
>> see
>> how that method should be part of Hibernate nor how you'd expect to be 
>> able
>> to configure Hibernate so that it would do that transparently.
>>
> the switch of lazyexception to null would work wit jaxb. Otherwise you
> need some more low level integration not portable IIRC.
>
>
>> I still think the cleanest solution would be to have DTOs, which is
>> why I'd argue that such a halve solution shouldn't be part of Hibernate.
>>
>
> Think we all agree (or agreed already ;)) but created this thread
> cause i saw it often enough to be a need.
>
>
>>
>> Mit freundlichen Grüßen,
>> --
>> *Christian Beikov*
>> Am 04.05.2017 um 18:00 schrieb Romain Manni-Bucau:
>>
>>
>>
>> 2017-05-04 17:33 GMT+02:00 Steve Ebersole :
>>
>>> What exactly would this "utility one level further than existing
>>> ones" do?
>>>
>>>
>> Multiple options are possible but one is to return null instead of
>> throwing lazy exception for instance.
>>
>>
>>> And for what it is worth, IMO the new Navigable model in 6.0 will
>>> again
>>> help here.  Especially in conjunction with the Navigable visitation
>>> support.
>>>
>>
>> I'm not familiar enough but if it providers for each member a way to
>> know if it is loaded or not it can work.
>>
>>
>>>
>>> On Thu, May 4, 2017 at 10:27 AM Christian Beikov <
>>> christian.bei...@gmail.com>
>>> wrote:
>>>
>>> > Well that is again exactly what a DTO is good for. If you as
>>> developer
>>> > want the groups to be available, you add a list of groups to that
>>> > special DTO type for that use case. In your data access layer you
>>> > somehow populate that, which is 

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Steve Ebersole]

I should clarify... if your `serialzer#serialize` call is not "recursively"
calling into this check then my example would not work; but then again,
neither would yours

On Thu, May 4, 2017, 12:26 PM Steve Ebersole  wrote:

> Hibernate#isInitialized is an overloaded method.  I think you want to look
> at the different forms.
>
> And yes, Navigable will define visitor-based navigation. Hence the name ;)
>
> On Thu, May 4, 2017, 12:18 PM Romain Manni-Bucau 
> wrote:
>
>> 2017-05-04 19:16 GMT+02:00 Steve Ebersole :
>>
>>> But your psuedo code is really just the same as:
>>>
>>> AnEntity e = find();
>>> if ( isInitialized( e ) ) {
>>> serializer.serialize(e);
>>> }
>>>
>>
>> no cause it is done in the graph visitor and not just the root, that's
>> the key difference.
>>
>>
>>>
>>> boolean isInitialized(Object e) {
>>> return Hibernate.isInitialized( e );
>>> }
>>>
>>> What I was getting at with the 6.0 + Navigavble discussion is that it
>>> would be better to base this "isInitialized" on these Navigables instead.
>>> A Navigable is a polymorphic reference that might be an entity, a
>>> persistent attribute, a "collection element", etc.
>>>
>>
>> Would need to see it in a more concrete version but sounds tempting,
>> would it integrate a visitor - handling cycles?
>>
>>
>>>
>>>
>>> On Thu, May 4, 2017 at 11:46 AM Romain Manni-Bucau <
>>> rmannibu...@gmail.com> wrote:
>>>
 2017-05-04 18:42 GMT+02:00 Christian Beikov :

> Detecting if an object is initialized should be as easy as calling "
> Hibernate.isInitialized(object)". If you want to know whether a
> specic attribute of an object is initialized you'd use 
> "Hibernate.isPropertyInitialized(object,
> attributeName)". What you want is some kind of integration that makes
> use of these two methods, so that if they return false, a null value is
> used when serializing objects to XML/JSON via JAXB/JSONB. Is that correct?
>

 Almost, I would like one able to just disable it, this way the
 serializer doesnt need anything or knowledge of hibernate. Worse case we
 need to integrate with the serializer in a way close to the one i proposed
 for johnzon before.

 In pseudo code it would be:

 AnEntity e = find();
 Hibernate.disableLazyExceptionWithNull(e);
 serializer.serialize(e);


> I don't know of any hook in JAXB that could be used to put that code
> into so it works out as you'd expect it. The only other way I can think 
> of,
> is nulling the properties explicitly which could be done quite easily. You
> probably gonna need just a single recursive method to do that. I don't see
> how that method should be part of Hibernate nor how you'd expect to be 
> able
> to configure Hibernate so that it would do that transparently.
>
 the switch of lazyexception to null would work wit jaxb. Otherwise you
 need some more low level integration not portable IIRC.


> I still think the cleanest solution would be to have DTOs, which is
> why I'd argue that such a halve solution shouldn't be part of Hibernate.
>

 Think we all agree (or agreed already ;)) but created this thread cause
 i saw it often enough to be a need.


>
> Mit freundlichen Grüßen,
> --
> *Christian Beikov*
> Am 04.05.2017 um 18:00 schrieb Romain Manni-Bucau:
>
>
>
> 2017-05-04 17:33 GMT+02:00 Steve Ebersole :
>
>> What exactly would this "utility one level further than existing
>> ones" do?
>>
>>
> Multiple options are possible but one is to return null instead of
> throwing lazy exception for instance.
>
>
>> And for what it is worth, IMO the new Navigable model in 6.0 will
>> again
>> help here.  Especially in conjunction with the Navigable visitation
>> support.
>>
>
> I'm not familiar enough but if it providers for each member a way to
> know if it is loaded or not it can work.
>
>
>>
>> On Thu, May 4, 2017 at 10:27 AM Christian Beikov <
>> christian.bei...@gmail.com>
>> wrote:
>>
>> > Well that is again exactly what a DTO is good for. If you as
>> developer
>> > want the groups to be available, you add a list of groups to that
>> > special DTO type for that use case. In your data access layer you
>> > somehow populate that, which is normally done by using some mapper
>> > library like MapStruct or Dozer and then JAXB/JSONB can just work
>> with
>> > the DTO type without any problems.
>> >
>> > Now if you forget to add a JOIN FETCH to your query and you end up
>> with
>> > N+1 queries, that's a different problem, just like the amount of
>> > boilerplate code needed for having DTO types for every use 

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Steve Ebersole]

Hibernate#isInitialized is an overloaded method.  I think you want to look
at the different forms.

And yes, Navigable will define visitor-based navigation. Hence the name ;)

On Thu, May 4, 2017, 12:18 PM Romain Manni-Bucau 
wrote:

> 2017-05-04 19:16 GMT+02:00 Steve Ebersole :
>
>> But your psuedo code is really just the same as:
>>
>> AnEntity e = find();
>> if ( isInitialized( e ) ) {
>> serializer.serialize(e);
>> }
>>
>
> no cause it is done in the graph visitor and not just the root, that's the
> key difference.
>
>
>>
>> boolean isInitialized(Object e) {
>> return Hibernate.isInitialized( e );
>> }
>>
>> What I was getting at with the 6.0 + Navigavble discussion is that it
>> would be better to base this "isInitialized" on these Navigables instead.
>> A Navigable is a polymorphic reference that might be an entity, a
>> persistent attribute, a "collection element", etc.
>>
>
> Would need to see it in a more concrete version but sounds tempting, would
> it integrate a visitor - handling cycles?
>
>
>>
>>
>> On Thu, May 4, 2017 at 11:46 AM Romain Manni-Bucau 
>> wrote:
>>
>>> 2017-05-04 18:42 GMT+02:00 Christian Beikov 
>>> :
>>>
 Detecting if an object is initialized should be as easy as calling "
 Hibernate.isInitialized(object)". If you want to know whether a specic
 attribute of an object is initialized you'd use 
 "Hibernate.isPropertyInitialized(object,
 attributeName)". What you want is some kind of integration that makes
 use of these two methods, so that if they return false, a null value is
 used when serializing objects to XML/JSON via JAXB/JSONB. Is that correct?

>>>
>>> Almost, I would like one able to just disable it, this way the
>>> serializer doesnt need anything or knowledge of hibernate. Worse case we
>>> need to integrate with the serializer in a way close to the one i proposed
>>> for johnzon before.
>>>
>>> In pseudo code it would be:
>>>
>>> AnEntity e = find();
>>> Hibernate.disableLazyExceptionWithNull(e);
>>> serializer.serialize(e);
>>>
>>>
 I don't know of any hook in JAXB that could be used to put that code
 into so it works out as you'd expect it. The only other way I can think of,
 is nulling the properties explicitly which could be done quite easily. You
 probably gonna need just a single recursive method to do that. I don't see
 how that method should be part of Hibernate nor how you'd expect to be able
 to configure Hibernate so that it would do that transparently.

>>> the switch of lazyexception to null would work wit jaxb. Otherwise you
>>> need some more low level integration not portable IIRC.
>>>
>>>
 I still think the cleanest solution would be to have DTOs, which is why
 I'd argue that such a halve solution shouldn't be part of Hibernate.

>>>
>>> Think we all agree (or agreed already ;)) but created this thread cause
>>> i saw it often enough to be a need.
>>>
>>>

 Mit freundlichen Grüßen,
 --
 *Christian Beikov*
 Am 04.05.2017 um 18:00 schrieb Romain Manni-Bucau:



 2017-05-04 17:33 GMT+02:00 Steve Ebersole :

> What exactly would this "utility one level further than existing ones"
> do?
>
>
 Multiple options are possible but one is to return null instead of
 throwing lazy exception for instance.


> And for what it is worth, IMO the new Navigable model in 6.0 will again
> help here.  Especially in conjunction with the Navigable visitation
> support.
>

 I'm not familiar enough but if it providers for each member a way to
 know if it is loaded or not it can work.


>
> On Thu, May 4, 2017 at 10:27 AM Christian Beikov <
> christian.bei...@gmail.com>
> wrote:
>
> > Well that is again exactly what a DTO is good for. If you as
> developer
> > want the groups to be available, you add a list of groups to that
> > special DTO type for that use case. In your data access layer you
> > somehow populate that, which is normally done by using some mapper
> > library like MapStruct or Dozer and then JAXB/JSONB can just work
> with
> > the DTO type without any problems.
> >
> > Now if you forget to add a JOIN FETCH to your query and you end up
> with
> > N+1 queries, that's a different problem, just like the amount of
> > boilerplate code needed for having DTO types for every use case.
> That I
> > try to solve with Blaze-Persistence Entity Views.
> >
> > Just a quick example to make my point here. If you have a REST
> endpoint
> > /user/{id} and want to provide the list of group names along with the
> > user information, you'd create a UserInfoDTO.
> >
> > @EntityView(User.class)
> > interface UserInfoDTO {
> >String 

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Romain Manni-Bucau]

2017-05-04 19:16 GMT+02:00 Steve Ebersole :

> But your psuedo code is really just the same as:
>
> AnEntity e = find();
> if ( isInitialized( e ) ) {
> serializer.serialize(e);
> }
>

no cause it is done in the graph visitor and not just the root, that's the
key difference.


>
> boolean isInitialized(Object e) {
> return Hibernate.isInitialized( e );
> }
>
> What I was getting at with the 6.0 + Navigavble discussion is that it
> would be better to base this "isInitialized" on these Navigables instead.
> A Navigable is a polymorphic reference that might be an entity, a
> persistent attribute, a "collection element", etc.
>

Would need to see it in a more concrete version but sounds tempting, would
it integrate a visitor - handling cycles?


>
>
> On Thu, May 4, 2017 at 11:46 AM Romain Manni-Bucau 
> wrote:
>
>> 2017-05-04 18:42 GMT+02:00 Christian Beikov :
>>
>>> Detecting if an object is initialized should be as easy as calling "
>>> Hibernate.isInitialized(object)". If you want to know whether a specic
>>> attribute of an object is initialized you'd use 
>>> "Hibernate.isPropertyInitialized(object,
>>> attributeName)". What you want is some kind of integration that makes
>>> use of these two methods, so that if they return false, a null value is
>>> used when serializing objects to XML/JSON via JAXB/JSONB. Is that correct?
>>>
>>
>> Almost, I would like one able to just disable it, this way the serializer
>> doesnt need anything or knowledge of hibernate. Worse case we need to
>> integrate with the serializer in a way close to the one i proposed for
>> johnzon before.
>>
>> In pseudo code it would be:
>>
>> AnEntity e = find();
>> Hibernate.disableLazyExceptionWithNull(e);
>> serializer.serialize(e);
>>
>>
>>> I don't know of any hook in JAXB that could be used to put that code
>>> into so it works out as you'd expect it. The only other way I can think of,
>>> is nulling the properties explicitly which could be done quite easily. You
>>> probably gonna need just a single recursive method to do that. I don't see
>>> how that method should be part of Hibernate nor how you'd expect to be able
>>> to configure Hibernate so that it would do that transparently.
>>>
>> the switch of lazyexception to null would work wit jaxb. Otherwise you
>> need some more low level integration not portable IIRC.
>>
>>
>>> I still think the cleanest solution would be to have DTOs, which is why
>>> I'd argue that such a halve solution shouldn't be part of Hibernate.
>>>
>>
>> Think we all agree (or agreed already ;)) but created this thread cause i
>> saw it often enough to be a need.
>>
>>
>>>
>>> Mit freundlichen Grüßen,
>>> --
>>> *Christian Beikov*
>>> Am 04.05.2017 um 18:00 schrieb Romain Manni-Bucau:
>>>
>>>
>>>
>>> 2017-05-04 17:33 GMT+02:00 Steve Ebersole :
>>>
 What exactly would this "utility one level further than existing ones"
 do?


>>> Multiple options are possible but one is to return null instead of
>>> throwing lazy exception for instance.
>>>
>>>
 And for what it is worth, IMO the new Navigable model in 6.0 will again
 help here.  Especially in conjunction with the Navigable visitation
 support.

>>>
>>> I'm not familiar enough but if it providers for each member a way to
>>> know if it is loaded or not it can work.
>>>
>>>

 On Thu, May 4, 2017 at 10:27 AM Christian Beikov <
 christian.bei...@gmail.com>
 wrote:

 > Well that is again exactly what a DTO is good for. If you as developer
 > want the groups to be available, you add a list of groups to that
 > special DTO type for that use case. In your data access layer you
 > somehow populate that, which is normally done by using some mapper
 > library like MapStruct or Dozer and then JAXB/JSONB can just work with
 > the DTO type without any problems.
 >
 > Now if you forget to add a JOIN FETCH to your query and you end up
 with
 > N+1 queries, that's a different problem, just like the amount of
 > boilerplate code needed for having DTO types for every use case. That
 I
 > try to solve with Blaze-Persistence Entity Views.
 >
 > Just a quick example to make my point here. If you have a REST
 endpoint
 > /user/{id} and want to provide the list of group names along with the
 > user information, you'd create a UserInfoDTO.
 >
 > @EntityView(User.class)
 > interface UserInfoDTO {
 >String getUsername();
 >@Mapping("groups.name")
 >List getGroups();
 > }
 >
 > Your repository returns an object of that type and you just pass that
 > object through so JAXB/JSONB can do their work. The mapping
 information
 > in the DTO is applied on a "source query" i.e. only doing the work
 > absolutely necessary to satisfy the requested projection.
 >
 > 

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Steve Ebersole]

But your psuedo code is really just the same as:

AnEntity e = find();
if ( isInitialized( e ) ) {
serializer.serialize(e);
}

boolean isInitialized(Object e) {
return Hibernate.isInitialized( e );
}

What I was getting at with the 6.0 + Navigavble discussion is that it would
be better to base this "isInitialized" on these Navigables instead.  A
Navigable is a polymorphic reference that might be an entity, a persistent
attribute, a "collection element", etc.


On Thu, May 4, 2017 at 11:46 AM Romain Manni-Bucau 
wrote:

> 2017-05-04 18:42 GMT+02:00 Christian Beikov :
>
>> Detecting if an object is initialized should be as easy as calling "
>> Hibernate.isInitialized(object)". If you want to know whether a specic
>> attribute of an object is initialized you'd use 
>> "Hibernate.isPropertyInitialized(object,
>> attributeName)". What you want is some kind of integration that makes
>> use of these two methods, so that if they return false, a null value is
>> used when serializing objects to XML/JSON via JAXB/JSONB. Is that correct?
>>
>
> Almost, I would like one able to just disable it, this way the serializer
> doesnt need anything or knowledge of hibernate. Worse case we need to
> integrate with the serializer in a way close to the one i proposed for
> johnzon before.
>
> In pseudo code it would be:
>
> AnEntity e = find();
> Hibernate.disableLazyExceptionWithNull(e);
> serializer.serialize(e);
>
>
>> I don't know of any hook in JAXB that could be used to put that code into
>> so it works out as you'd expect it. The only other way I can think of, is
>> nulling the properties explicitly which could be done quite easily. You
>> probably gonna need just a single recursive method to do that. I don't see
>> how that method should be part of Hibernate nor how you'd expect to be able
>> to configure Hibernate so that it would do that transparently.
>>
> the switch of lazyexception to null would work wit jaxb. Otherwise you
> need some more low level integration not portable IIRC.
>
>
>> I still think the cleanest solution would be to have DTOs, which is why
>> I'd argue that such a halve solution shouldn't be part of Hibernate.
>>
>
> Think we all agree (or agreed already ;)) but created this thread cause i
> saw it often enough to be a need.
>
>
>>
>> Mit freundlichen Grüßen,
>> --
>> *Christian Beikov*
>> Am 04.05.2017 um 18:00 schrieb Romain Manni-Bucau:
>>
>>
>>
>> 2017-05-04 17:33 GMT+02:00 Steve Ebersole :
>>
>>> What exactly would this "utility one level further than existing ones"
>>> do?
>>>
>>>
>> Multiple options are possible but one is to return null instead of
>> throwing lazy exception for instance.
>>
>>
>>> And for what it is worth, IMO the new Navigable model in 6.0 will again
>>> help here.  Especially in conjunction with the Navigable visitation
>>> support.
>>>
>>
>> I'm not familiar enough but if it providers for each member a way to know
>> if it is loaded or not it can work.
>>
>>
>>>
>>> On Thu, May 4, 2017 at 10:27 AM Christian Beikov <
>>> christian.bei...@gmail.com>
>>> wrote:
>>>
>>> > Well that is again exactly what a DTO is good for. If you as developer
>>> > want the groups to be available, you add a list of groups to that
>>> > special DTO type for that use case. In your data access layer you
>>> > somehow populate that, which is normally done by using some mapper
>>> > library like MapStruct or Dozer and then JAXB/JSONB can just work with
>>> > the DTO type without any problems.
>>> >
>>> > Now if you forget to add a JOIN FETCH to your query and you end up with
>>> > N+1 queries, that's a different problem, just like the amount of
>>> > boilerplate code needed for having DTO types for every use case. That I
>>> > try to solve with Blaze-Persistence Entity Views.
>>> >
>>> > Just a quick example to make my point here. If you have a REST endpoint
>>> > /user/{id} and want to provide the list of group names along with the
>>> > user information, you'd create a UserInfoDTO.
>>> >
>>> > @EntityView(User.class)
>>> > interface UserInfoDTO {
>>> >String getUsername();
>>> >@Mapping("groups.name")
>>> >List getGroups();
>>> > }
>>> >
>>> > Your repository returns an object of that type and you just pass that
>>> > object through so JAXB/JSONB can do their work. The mapping information
>>> > in the DTO is applied on a "source query" i.e. only doing the work
>>> > absolutely necessary to satisfy the requested projection.
>>> >
>>> > Implementing this by hand is by no means impossible, but rather
>>> > inconvenient I'd say, which is probably why you are seeking for other
>>> > solutions.
>>> >
>>> > In the end, you can only try to create a minimal DTO that has exactly
>>> > the fields you want to be serialized or annotate your existing entities
>>> > with those "ignore" annotations and hope for the best. I don't see how
>>> > hibernate could or should help in any of the two 

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Romain Manni-Bucau]

2017-05-04 18:42 GMT+02:00 Christian Beikov :

> Detecting if an object is initialized should be as easy as calling "
> Hibernate.isInitialized(object)". If you want to know whether a specic
> attribute of an object is initialized you'd use 
> "Hibernate.isPropertyInitialized(object,
> attributeName)". What you want is some kind of integration that makes use
> of these two methods, so that if they return false, a null value is used
> when serializing objects to XML/JSON via JAXB/JSONB. Is that correct?
>

Almost, I would like one able to just disable it, this way the serializer
doesnt need anything or knowledge of hibernate. Worse case we need to
integrate with the serializer in a way close to the one i proposed for
johnzon before.

In pseudo code it would be:

AnEntity e = find();
Hibernate.disableLazyExceptionWithNull(e);
serializer.serialize(e);


> I don't know of any hook in JAXB that could be used to put that code into
> so it works out as you'd expect it. The only other way I can think of, is
> nulling the properties explicitly which could be done quite easily. You
> probably gonna need just a single recursive method to do that. I don't see
> how that method should be part of Hibernate nor how you'd expect to be able
> to configure Hibernate so that it would do that transparently.
>
the switch of lazyexception to null would work wit jaxb. Otherwise you need
some more low level integration not portable IIRC.


> I still think the cleanest solution would be to have DTOs, which is why
> I'd argue that such a halve solution shouldn't be part of Hibernate.
>

Think we all agree (or agreed already ;)) but created this thread cause i
saw it often enough to be a need.


>
> Mit freundlichen Grüßen,
> --
> *Christian Beikov*
> Am 04.05.2017 um 18:00 schrieb Romain Manni-Bucau:
>
>
>
> 2017-05-04 17:33 GMT+02:00 Steve Ebersole :
>
>> What exactly would this "utility one level further than existing ones" do?
>>
>>
> Multiple options are possible but one is to return null instead of
> throwing lazy exception for instance.
>
>
>> And for what it is worth, IMO the new Navigable model in 6.0 will again
>> help here.  Especially in conjunction with the Navigable visitation
>> support.
>>
>
> I'm not familiar enough but if it providers for each member a way to know
> if it is loaded or not it can work.
>
>
>>
>> On Thu, May 4, 2017 at 10:27 AM Christian Beikov <
>> christian.bei...@gmail.com>
>> wrote:
>>
>> > Well that is again exactly what a DTO is good for. If you as developer
>> > want the groups to be available, you add a list of groups to that
>> > special DTO type for that use case. In your data access layer you
>> > somehow populate that, which is normally done by using some mapper
>> > library like MapStruct or Dozer and then JAXB/JSONB can just work with
>> > the DTO type without any problems.
>> >
>> > Now if you forget to add a JOIN FETCH to your query and you end up with
>> > N+1 queries, that's a different problem, just like the amount of
>> > boilerplate code needed for having DTO types for every use case. That I
>> > try to solve with Blaze-Persistence Entity Views.
>> >
>> > Just a quick example to make my point here. If you have a REST endpoint
>> > /user/{id} and want to provide the list of group names along with the
>> > user information, you'd create a UserInfoDTO.
>> >
>> > @EntityView(User.class)
>> > interface UserInfoDTO {
>> >String getUsername();
>> >@Mapping("groups.name")
>> >List getGroups();
>> > }
>> >
>> > Your repository returns an object of that type and you just pass that
>> > object through so JAXB/JSONB can do their work. The mapping information
>> > in the DTO is applied on a "source query" i.e. only doing the work
>> > absolutely necessary to satisfy the requested projection.
>> >
>> > Implementing this by hand is by no means impossible, but rather
>> > inconvenient I'd say, which is probably why you are seeking for other
>> > solutions.
>> >
>> > In the end, you can only try to create a minimal DTO that has exactly
>> > the fields you want to be serialized or annotate your existing entities
>> > with those "ignore" annotations and hope for the best. I don't see how
>> > hibernate could or should help in any of the two cases.
>> >
>> > Mit freundlichen Grüßen,
>> > 
>> 
>> > *Christian Beikov*
>> > Am 04.05.2017 um 16:59 schrieb Romain Manni-Bucau:
>> > > Sure. If you add any conversion logic then you are clearly out of
>> > > hibernate scope and the problem doesnt appear anymore. Here is a
>> > > trivial example (hopefully trivial at least ;))
>> > >
>> > > User 1 - n Group
>> > >
>> > > In json we would get something like {username:...,groups:[group1,
>> > > group2]}, no issue to know if group should be loaded or not since this
>> > > part of the logic is in the mapper layer.
>> > >
>> > > So yes you can say "not my 

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Romain Manni-Bucau]

2017-05-04 17:33 GMT+02:00 Steve Ebersole :

> What exactly would this "utility one level further than existing ones" do?
>
>
Multiple options are possible but one is to return null instead of throwing
lazy exception for instance.


> And for what it is worth, IMO the new Navigable model in 6.0 will again
> help here.  Especially in conjunction with the Navigable visitation
> support.
>

I'm not familiar enough but if it providers for each member a way to know
if it is loaded or not it can work.


>
> On Thu, May 4, 2017 at 10:27 AM Christian Beikov <
> christian.bei...@gmail.com>
> wrote:
>
> > Well that is again exactly what a DTO is good for. If you as developer
> > want the groups to be available, you add a list of groups to that
> > special DTO type for that use case. In your data access layer you
> > somehow populate that, which is normally done by using some mapper
> > library like MapStruct or Dozer and then JAXB/JSONB can just work with
> > the DTO type without any problems.
> >
> > Now if you forget to add a JOIN FETCH to your query and you end up with
> > N+1 queries, that's a different problem, just like the amount of
> > boilerplate code needed for having DTO types for every use case. That I
> > try to solve with Blaze-Persistence Entity Views.
> >
> > Just a quick example to make my point here. If you have a REST endpoint
> > /user/{id} and want to provide the list of group names along with the
> > user information, you'd create a UserInfoDTO.
> >
> > @EntityView(User.class)
> > interface UserInfoDTO {
> >String getUsername();
> >@Mapping("groups.name")
> >List getGroups();
> > }
> >
> > Your repository returns an object of that type and you just pass that
> > object through so JAXB/JSONB can do their work. The mapping information
> > in the DTO is applied on a "source query" i.e. only doing the work
> > absolutely necessary to satisfy the requested projection.
> >
> > Implementing this by hand is by no means impossible, but rather
> > inconvenient I'd say, which is probably why you are seeking for other
> > solutions.
> >
> > In the end, you can only try to create a minimal DTO that has exactly
> > the fields you want to be serialized or annotate your existing entities
> > with those "ignore" annotations and hope for the best. I don't see how
> > hibernate could or should help in any of the two cases.
> >
> > Mit freundlichen Grüßen,
> > 
> > *Christian Beikov*
> > Am 04.05.2017 um 16:59 schrieb Romain Manni-Bucau:
> > > Sure. If you add any conversion logic then you are clearly out of
> > > hibernate scope and the problem doesnt appear anymore. Here is a
> > > trivial example (hopefully trivial at least ;))
> > >
> > > User 1 - n Group
> > >
> > > In json we would get something like {username:...,groups:[group1,
> > > group2]}, no issue to know if group should be loaded or not since this
> > > part of the logic is in the mapper layer.
> > >
> > > So yes you can say "not my problem" but next framework will
> > > immediately ask "how do i know" and you likely end like all
> > > spring-data-rest recommandation with a specific mapping and not a
> > > framework solution which is the target of that thread - at least what
> > > I tried to explain ;).
> > >
> > > 2017-05-04 16:41 GMT+02:00 Christian Beikov
> > > >:
> > >
> > > I don't understand what you mean by "you put that logic in the
> > > conversion", could you elaborate?
> > >
> > >
> > > Mit freundlichen Grüßen,
> > >
> >  
> 
> > > *Christian Beikov*
> > > Am 04.05.2017 um 16:32 schrieb Romain Manni-Bucau:
> > >> Few more points:
> > >>
> > >> 1. Dto dont help at any moment - or you put that logic in the
> > >> conversion and you are back to start
> > >> 2. Making jaxb/jsonb easy to integrate is the goal IMO. No need
> > >> to integrate with them but just provide some utility one level
> > >> further than existing ones
> > >>
> > >> Le 4 mai 2017 16:13, "Steve Ebersole"  > >> > a écrit :
> > >>
> > >> Oops, that (3) in previous reply should have read:
> > >> 3. supporting each format creates a new "optional" library
> > >> dependency
> > >>
> > >> Overall, I like Christian's approach as a potential
> > >> generalized approach to
> > >> this.  Basically a combination of
> > >>
> > >>1. a query used to provide the "view source values"
> > >>2. some indication of how to map those "source values" to
> > >> your view model
> > >>
> > >>
> > >> And again, I think 6.0's improved dynamic-instantiation
> > >> queries are a
> > >> simple, already-built-in way to achieve that for most cases.
> > >> But I 

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Steve Ebersole]

What exactly would this "utility one level further than existing ones" do?

And for what it is worth, IMO the new Navigable model in 6.0 will again
help here.  Especially in conjunction with the Navigable visitation support.

On Thu, May 4, 2017 at 10:27 AM Christian Beikov 
wrote:

> Well that is again exactly what a DTO is good for. If you as developer
> want the groups to be available, you add a list of groups to that
> special DTO type for that use case. In your data access layer you
> somehow populate that, which is normally done by using some mapper
> library like MapStruct or Dozer and then JAXB/JSONB can just work with
> the DTO type without any problems.
>
> Now if you forget to add a JOIN FETCH to your query and you end up with
> N+1 queries, that's a different problem, just like the amount of
> boilerplate code needed for having DTO types for every use case. That I
> try to solve with Blaze-Persistence Entity Views.
>
> Just a quick example to make my point here. If you have a REST endpoint
> /user/{id} and want to provide the list of group names along with the
> user information, you'd create a UserInfoDTO.
>
> @EntityView(User.class)
> interface UserInfoDTO {
>String getUsername();
>@Mapping("groups.name")
>List getGroups();
> }
>
> Your repository returns an object of that type and you just pass that
> object through so JAXB/JSONB can do their work. The mapping information
> in the DTO is applied on a "source query" i.e. only doing the work
> absolutely necessary to satisfy the requested projection.
>
> Implementing this by hand is by no means impossible, but rather
> inconvenient I'd say, which is probably why you are seeking for other
> solutions.
>
> In the end, you can only try to create a minimal DTO that has exactly
> the fields you want to be serialized or annotate your existing entities
> with those "ignore" annotations and hope for the best. I don't see how
> hibernate could or should help in any of the two cases.
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> Am 04.05.2017 um 16:59 schrieb Romain Manni-Bucau:
> > Sure. If you add any conversion logic then you are clearly out of
> > hibernate scope and the problem doesnt appear anymore. Here is a
> > trivial example (hopefully trivial at least ;))
> >
> > User 1 - n Group
> >
> > In json we would get something like {username:...,groups:[group1,
> > group2]}, no issue to know if group should be loaded or not since this
> > part of the logic is in the mapper layer.
> >
> > So yes you can say "not my problem" but next framework will
> > immediately ask "how do i know" and you likely end like all
> > spring-data-rest recommandation with a specific mapping and not a
> > framework solution which is the target of that thread - at least what
> > I tried to explain ;).
> >
> > 2017-05-04 16:41 GMT+02:00 Christian Beikov
> > >:
> >
> > I don't understand what you mean by "you put that logic in the
> > conversion", could you elaborate?
> >
> >
> > Mit freundlichen Grüßen,
> >
>  
> > *Christian Beikov*
> > Am 04.05.2017 um 16:32 schrieb Romain Manni-Bucau:
> >> Few more points:
> >>
> >> 1. Dto dont help at any moment - or you put that logic in the
> >> conversion and you are back to start
> >> 2. Making jaxb/jsonb easy to integrate is the goal IMO. No need
> >> to integrate with them but just provide some utility one level
> >> further than existing ones
> >>
> >> Le 4 mai 2017 16:13, "Steve Ebersole"  >> > a écrit :
> >>
> >> Oops, that (3) in previous reply should have read:
> >> 3. supporting each format creates a new "optional" library
> >> dependency
> >>
> >> Overall, I like Christian's approach as a potential
> >> generalized approach to
> >> this.  Basically a combination of
> >>
> >>1. a query used to provide the "view source values"
> >>2. some indication of how to map those "source values" to
> >> your view model
> >>
> >>
> >> And again, I think 6.0's improved dynamic-instantiation
> >> queries are a
> >> simple, already-built-in way to achieve that for most cases.
> >> But I am open
> >> to discussing a way to supply that combination via API if we
> >> deem that
> >> would be good - although then I'd also question how the current
> >> TupleTransformer does not meet that need.
> >>
> >> On Thu, May 4, 2017 at 8:43 AM Steve Ebersole
> >> > wrote:
> >>
> >> > Were there a standard "represent something in XML-ish
> >> format" contract
> >> > portable 

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Christian Beikov]

Well that is again exactly what a DTO is good for. If you as developer 
want the groups to be available, you add a list of groups to that 
special DTO type for that use case. In your data access layer you 
somehow populate that, which is normally done by using some mapper 
library like MapStruct or Dozer and then JAXB/JSONB can just work with 
the DTO type without any problems.

Now if you forget to add a JOIN FETCH to your query and you end up with 
N+1 queries, that's a different problem, just like the amount of 
boilerplate code needed for having DTO types for every use case. That I 
try to solve with Blaze-Persistence Entity Views.

Just a quick example to make my point here. If you have a REST endpoint 
/user/{id} and want to provide the list of group names along with the 
user information, you'd create a UserInfoDTO.

@EntityView(User.class)
interface UserInfoDTO {
   String getUsername();
   @Mapping("groups.name")
   List getGroups();
}

Your repository returns an object of that type and you just pass that 
object through so JAXB/JSONB can do their work. The mapping information 
in the DTO is applied on a "source query" i.e. only doing the work 
absolutely necessary to satisfy the requested projection.

Implementing this by hand is by no means impossible, but rather 
inconvenient I'd say, which is probably why you are seeking for other 
solutions.

In the end, you can only try to create a minimal DTO that has exactly 
the fields you want to be serialized or annotate your existing entities 
with those "ignore" annotations and hope for the best. I don't see how 
hibernate could or should help in any of the two cases.

Mit freundlichen Grüßen,

*Christian Beikov*
Am 04.05.2017 um 16:59 schrieb Romain Manni-Bucau:
> Sure. If you add any conversion logic then you are clearly out of 
> hibernate scope and the problem doesnt appear anymore. Here is a 
> trivial example (hopefully trivial at least ;))
>
> User 1 - n Group
>
> In json we would get something like {username:...,groups:[group1, 
> group2]}, no issue to know if group should be loaded or not since this 
> part of the logic is in the mapper layer.
>
> So yes you can say "not my problem" but next framework will 
> immediately ask "how do i know" and you likely end like all 
> spring-data-rest recommandation with a specific mapping and not a 
> framework solution which is the target of that thread - at least what 
> I tried to explain ;).
>
> 2017-05-04 16:41 GMT+02:00 Christian Beikov 
> >:
>
> I don't understand what you mean by "you put that logic in the
> conversion", could you elaborate?
>
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> Am 04.05.2017 um 16:32 schrieb Romain Manni-Bucau:
>> Few more points:
>>
>> 1. Dto dont help at any moment - or you put that logic in the
>> conversion and you are back to start
>> 2. Making jaxb/jsonb easy to integrate is the goal IMO. No need
>> to integrate with them but just provide some utility one level
>> further than existing ones
>>
>> Le 4 mai 2017 16:13, "Steve Ebersole" > > a écrit :
>>
>> Oops, that (3) in previous reply should have read:
>> 3. supporting each format creates a new "optional" library
>> dependency
>>
>> Overall, I like Christian's approach as a potential
>> generalized approach to
>> this.  Basically a combination of
>>
>>1. a query used to provide the "view source values"
>>2. some indication of how to map those "source values" to
>> your view model
>>
>>
>> And again, I think 6.0's improved dynamic-instantiation
>> queries are a
>> simple, already-built-in way to achieve that for most cases. 
>> But I am open
>> to discussing a way to supply that combination via API if we
>> deem that
>> would be good - although then I'd also question how the current
>> TupleTransformer does not meet that need.
>>
>> On Thu, May 4, 2017 at 8:43 AM Steve Ebersole
>> > wrote:
>>
>> > Were there a standard "represent something in XML-ish
>> format" contract
>> > portable across a number of formats (XML, JAXB, JSON, etc)
>> then I'd be more
>> > inclined to agree with this.  But as it is, supporting this
>> would mean
>> > Hibernate implementing multiple such contracts, one per
>> format.  However,
>> >
>> >1. these formats are not our core competency
>> >2. maintaining a complete set of these transformers
>> across all the
>> >popular formats du-jour is a large 

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Romain Manni-Bucau]

Sure. If you add any conversion logic then you are clearly out of hibernate
scope and the problem doesnt appear anymore. Here is a trivial example
(hopefully trivial at least ;))

User 1 - n Group

In json we would get something like {username:...,groups:[group1, group2]},
no issue to know if group should be loaded or not since this part of the
logic is in the mapper layer.

So yes you can say "not my problem" but next framework will immediately ask
"how do i know" and you likely end like all spring-data-rest recommandation
with a specific mapping and not a framework solution which is the target of
that thread - at least what I tried to explain ;).

2017-05-04 16:41 GMT+02:00 Christian Beikov :

> I don't understand what you mean by "you put that logic in the
> conversion", could you elaborate?
>
> Mit freundlichen Grüßen,
> --
> *Christian Beikov*
> Am 04.05.2017 um 16:32 schrieb Romain Manni-Bucau:
>
> Few more points:
>
> 1. Dto dont help at any moment - or you put that logic in the conversion
> and you are back to start
> 2. Making jaxb/jsonb easy to integrate is the goal IMO. No need to
> integrate with them but just provide some utility one level further than
> existing ones
>
> Le 4 mai 2017 16:13, "Steve Ebersole"  a écrit :
>
>> Oops, that (3) in previous reply should have read:
>> 3. supporting each format creates a new "optional" library dependency
>>
>> Overall, I like Christian's approach as a potential generalized approach
>> to
>> this.  Basically a combination of
>>
>>1. a query used to provide the "view source values"
>>2. some indication of how to map those "source values" to your view
>> model
>>
>>
>> And again, I think 6.0's improved dynamic-instantiation queries are a
>> simple, already-built-in way to achieve that for most cases.  But I am
>> open
>> to discussing a way to supply that combination via API if we deem that
>> would be good - although then I'd also question how the current
>> TupleTransformer does not meet that need.
>>
>> On Thu, May 4, 2017 at 8:43 AM Steve Ebersole 
>> wrote:
>>
>> > Were there a standard "represent something in XML-ish format" contract
>> > portable across a number of formats (XML, JAXB, JSON, etc) then I'd be
>> more
>> > inclined to agree with this.  But as it is, supporting this would mean
>> > Hibernate implementing multiple such contracts, one per format.
>> However,
>> >
>> >1. these formats are not our core competency
>> >2. maintaining a complete set of these transformers across all the
>> >popular formats du-jour is a large undertaking
>> >3. I am not convinced that
>> >
>> > All of these increase the technical risk.
>> >
>> > Additionally, to properly support this we'd really need the ability to
>> > then "map" multiple views for a given entity-graph-root.  What I mean by
>> > that, is that such DTO approaches often need multiple "views" of a given
>> > entity, e.g. a CompanyListDTO, CompanyOverviewDTO,
>> > CompanyDetailsGeneralDTO, etc for a Company entity.  The point of this
>> is
>> > that
>> >
>> >1. the transformers for these are specific to each DTO type and would
>> >be applied per-transformation
>> >2. were Hibernate to "provide" this for applications
>> >
>> > IMO the use of queries to obtain views is logical.  Populating each of
>> > those specific DTOs (CompanyListDTO, etc) in the most efficient way is
>> > going to require very different SQL for each DTO.  This implies some
>> kind
>> > of "mapping" to be able associate each DTO with query.
>> >
>> > Given 6.0's improved dynamic-instantiation support, I even think that
>> is a
>> > great solution as well *for most cases*.
>> >
>> > So, while my objection has a "practical impact" component, I also just
>> > question whether Hibernate integrating with each format's "serializer"
>> is
>> > the proper solution.
>> >
>> >
>> >
>> > On Thu, May 4, 2017 at 5:08 AM Christian Beikov <
>> > christian.bei...@gmail.com> wrote:
>> >
>> >> This is exactly what I am trying to do with Blaze-Persistence Entity
>> >> Views, making DTOs sexy and efficient :)
>> >>
>> >> Here a quick overview of how that looks like right now:
>> >>
>> >> https://persistence.blazebit.com/documentation/entity-view/m
>> anual/en_US/index.html#first-entity-view-query
>> >>
>> >> One of my targets is to make it possible to do something like this
>> >>
>> >> entityManager.createQuery("FROM Order o",
>> OrderDTO.class).getResultList()
>> >>
>> >> and get an optimal query, as well as objects with only the necessary
>> >> contents.
>> >>
>> >> Maybe we can collaborate on that somehow?
>> >>
>> >>
>> >> Mit freundlichen Grüßen,
>> >> 
>> 
>> >> *Christian Beikov*
>> >> Am 04.05.2017 um 10:20 schrieb Emmanuel Bernard:
>> >> > Following up a bit on my previous email.
>> >> >
>> >> > While a core integration might be best I 

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Christian Beikov]

I don't understand what you mean by "you put that logic in the 
conversion", could you elaborate?


Mit freundlichen Grüßen,

*Christian Beikov*
Am 04.05.2017 um 16:32 schrieb Romain Manni-Bucau:
> Few more points:
>
> 1. Dto dont help at any moment - or you put that logic in the 
> conversion and you are back to start
> 2. Making jaxb/jsonb easy to integrate is the goal IMO. No need to 
> integrate with them but just provide some utility one level further 
> than existing ones
>
> Le 4 mai 2017 16:13, "Steve Ebersole"  > a écrit :
>
> Oops, that (3) in previous reply should have read:
> 3. supporting each format creates a new "optional" library dependency
>
> Overall, I like Christian's approach as a potential generalized
> approach to
> this.  Basically a combination of
>
>1. a query used to provide the "view source values"
>2. some indication of how to map those "source values" to your
> view model
>
>
> And again, I think 6.0's improved dynamic-instantiation queries are a
> simple, already-built-in way to achieve that for most cases.  But
> I am open
> to discussing a way to supply that combination via API if we deem that
> would be good - although then I'd also question how the current
> TupleTransformer does not meet that need.
>
> On Thu, May 4, 2017 at 8:43 AM Steve Ebersole  > wrote:
>
> > Were there a standard "represent something in XML-ish format"
> contract
> > portable across a number of formats (XML, JAXB, JSON, etc) then
> I'd be more
> > inclined to agree with this.  But as it is, supporting this
> would mean
> > Hibernate implementing multiple such contracts, one per format. 
> However,
> >
> >1. these formats are not our core competency
> >2. maintaining a complete set of these transformers across
> all the
> >popular formats du-jour is a large undertaking
> >3. I am not convinced that
> >
> > All of these increase the technical risk.
> >
> > Additionally, to properly support this we'd really need the
> ability to
> > then "map" multiple views for a given entity-graph-root.  What I
> mean by
> > that, is that such DTO approaches often need multiple "views" of
> a given
> > entity, e.g. a CompanyListDTO, CompanyOverviewDTO,
> > CompanyDetailsGeneralDTO, etc for a Company entity. The point of
> this is
> > that
> >
> >1. the transformers for these are specific to each DTO type
> and would
> >be applied per-transformation
> >2. were Hibernate to "provide" this for applications
> >
> > IMO the use of queries to obtain views is logical. Populating
> each of
> > those specific DTOs (CompanyListDTO, etc) in the most efficient
> way is
> > going to require very different SQL for each DTO.  This implies
> some kind
> > of "mapping" to be able associate each DTO with query.
> >
> > Given 6.0's improved dynamic-instantiation support, I even think
> that is a
> > great solution as well *for most cases*.
> >
> > So, while my objection has a "practical impact" component, I
> also just
> > question whether Hibernate integrating with each format's
> "serializer" is
> > the proper solution.
> >
> >
> >
> > On Thu, May 4, 2017 at 5:08 AM Christian Beikov <
> > christian.bei...@gmail.com >
> wrote:
> >
> >> This is exactly what I am trying to do with Blaze-Persistence
> Entity
> >> Views, making DTOs sexy and efficient :)
> >>
> >> Here a quick overview of how that looks like right now:
> >>
> >>
> 
> https://persistence.blazebit.com/documentation/entity-view/manual/en_US/index.html#first-entity-view-query
> 
> 
> >>
> >> One of my targets is to make it possible to do something like this
> >>
> >> entityManager.createQuery("FROM Order o",
> OrderDTO.class).getResultList()
> >>
> >> and get an optimal query, as well as objects with only the
> necessary
> >> contents.
> >>
> >> Maybe we can collaborate on that somehow?
> >>
> >>
> >> Mit freundlichen Grüßen,
> >>
> 
> >> *Christian Beikov*
> >> Am 04.05.2017 um 10:20 schrieb Emmanuel Bernard:
> >> > Following up a bit on my previous email.
> >> >
> >> > While a core integration might be best I think, if there are
> too much
> >> > reluctance, we can start with a dedicated hibernate-dto or
> whatever
> >> > module or even 

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Romain Manni-Bucau]

Few more points:

1. Dto dont help at any moment - or you put that logic in the conversion
and you are back to start
2. Making jaxb/jsonb easy to integrate is the goal IMO. No need to
integrate with them but just provide some utility one level further than
existing ones

Le 4 mai 2017 16:13, "Steve Ebersole"  a écrit :

> Oops, that (3) in previous reply should have read:
> 3. supporting each format creates a new "optional" library dependency
>
> Overall, I like Christian's approach as a potential generalized approach to
> this.  Basically a combination of
>
>1. a query used to provide the "view source values"
>2. some indication of how to map those "source values" to your view
> model
>
>
> And again, I think 6.0's improved dynamic-instantiation queries are a
> simple, already-built-in way to achieve that for most cases.  But I am open
> to discussing a way to supply that combination via API if we deem that
> would be good - although then I'd also question how the current
> TupleTransformer does not meet that need.
>
> On Thu, May 4, 2017 at 8:43 AM Steve Ebersole  wrote:
>
> > Were there a standard "represent something in XML-ish format" contract
> > portable across a number of formats (XML, JAXB, JSON, etc) then I'd be
> more
> > inclined to agree with this.  But as it is, supporting this would mean
> > Hibernate implementing multiple such contracts, one per format.  However,
> >
> >1. these formats are not our core competency
> >2. maintaining a complete set of these transformers across all the
> >popular formats du-jour is a large undertaking
> >3. I am not convinced that
> >
> > All of these increase the technical risk.
> >
> > Additionally, to properly support this we'd really need the ability to
> > then "map" multiple views for a given entity-graph-root.  What I mean by
> > that, is that such DTO approaches often need multiple "views" of a given
> > entity, e.g. a CompanyListDTO, CompanyOverviewDTO,
> > CompanyDetailsGeneralDTO, etc for a Company entity.  The point of this is
> > that
> >
> >1. the transformers for these are specific to each DTO type and would
> >be applied per-transformation
> >2. were Hibernate to "provide" this for applications
> >
> > IMO the use of queries to obtain views is logical.  Populating each of
> > those specific DTOs (CompanyListDTO, etc) in the most efficient way is
> > going to require very different SQL for each DTO.  This implies some kind
> > of "mapping" to be able associate each DTO with query.
> >
> > Given 6.0's improved dynamic-instantiation support, I even think that is
> a
> > great solution as well *for most cases*.
> >
> > So, while my objection has a "practical impact" component, I also just
> > question whether Hibernate integrating with each format's "serializer" is
> > the proper solution.
> >
> >
> >
> > On Thu, May 4, 2017 at 5:08 AM Christian Beikov <
> > christian.bei...@gmail.com> wrote:
> >
> >> This is exactly what I am trying to do with Blaze-Persistence Entity
> >> Views, making DTOs sexy and efficient :)
> >>
> >> Here a quick overview of how that looks like right now:
> >>
> >> https://persistence.blazebit.com/documentation/entity-view/
> manual/en_US/index.html#first-entity-view-query
> >>
> >> One of my targets is to make it possible to do something like this
> >>
> >> entityManager.createQuery("FROM Order o",
> OrderDTO.class).getResultList()
> >>
> >> and get an optimal query, as well as objects with only the necessary
> >> contents.
> >>
> >> Maybe we can collaborate on that somehow?
> >>
> >>
> >> Mit freundlichen Grüßen,
> >> 
> 
> >> *Christian Beikov*
> >> Am 04.05.2017 um 10:20 schrieb Emmanuel Bernard:
> >> > Following up a bit on my previous email.
> >> >
> >> > While a core integration might be best I think, if there are too much
> >> > reluctance, we can start with a dedicated hibernate-dto or whatever
> >> > module or even separate project that makes life easier for these "pass
> >> > through" use cases. This could be in the form of a wrapper API of sort
> >> > and hence not affect existing Hibernate ORM APIs.
> >> >
> >> > Note that the ResultTransformer approach feels like it goes a long way
> >> > towards fixing the problem but as demonstrated in Vlad's article
> >> >
> >> https://vladmihalcea.com/2017/04/03/why-you-should-use-the-
> hibernate-resulttransformer-to-customize-result-set-mappings/
> >> > it still requires quite a bit of code and a special DTO constructor
> >> > object. That's what we need to get rid of I think.
> >> >
> >> > Emmanuel
> >> >
> >> > On Thu 17-05-04 10:04, Emmanuel Bernard wrote:
> >> >> I was very much in the Vlad, Steve, Christian camp until relatively
> >> >> recently. One of my main concern being that replacing a proxy by null
> >> >> was really sending the wrong message. So I was against having
> Hibernate
> >> >> ORM facilitate such a 

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Steve Ebersole]

Oops, that (3) in previous reply should have read:
3. supporting each format creates a new "optional" library dependency

Overall, I like Christian's approach as a potential generalized approach to
this.  Basically a combination of

   1. a query used to provide the "view source values"
   2. some indication of how to map those "source values" to your view model


And again, I think 6.0's improved dynamic-instantiation queries are a
simple, already-built-in way to achieve that for most cases.  But I am open
to discussing a way to supply that combination via API if we deem that
would be good - although then I'd also question how the current
TupleTransformer does not meet that need.

On Thu, May 4, 2017 at 8:43 AM Steve Ebersole  wrote:

> Were there a standard "represent something in XML-ish format" contract
> portable across a number of formats (XML, JAXB, JSON, etc) then I'd be more
> inclined to agree with this.  But as it is, supporting this would mean
> Hibernate implementing multiple such contracts, one per format.  However,
>
>1. these formats are not our core competency
>2. maintaining a complete set of these transformers across all the
>popular formats du-jour is a large undertaking
>3. I am not convinced that
>
> All of these increase the technical risk.
>
> Additionally, to properly support this we'd really need the ability to
> then "map" multiple views for a given entity-graph-root.  What I mean by
> that, is that such DTO approaches often need multiple "views" of a given
> entity, e.g. a CompanyListDTO, CompanyOverviewDTO,
> CompanyDetailsGeneralDTO, etc for a Company entity.  The point of this is
> that
>
>1. the transformers for these are specific to each DTO type and would
>be applied per-transformation
>2. were Hibernate to "provide" this for applications
>
> IMO the use of queries to obtain views is logical.  Populating each of
> those specific DTOs (CompanyListDTO, etc) in the most efficient way is
> going to require very different SQL for each DTO.  This implies some kind
> of "mapping" to be able associate each DTO with query.
>
> Given 6.0's improved dynamic-instantiation support, I even think that is a
> great solution as well *for most cases*.
>
> So, while my objection has a "practical impact" component, I also just
> question whether Hibernate integrating with each format's "serializer" is
> the proper solution.
>
>
>
> On Thu, May 4, 2017 at 5:08 AM Christian Beikov <
> christian.bei...@gmail.com> wrote:
>
>> This is exactly what I am trying to do with Blaze-Persistence Entity
>> Views, making DTOs sexy and efficient :)
>>
>> Here a quick overview of how that looks like right now:
>>
>> https://persistence.blazebit.com/documentation/entity-view/manual/en_US/index.html#first-entity-view-query
>>
>> One of my targets is to make it possible to do something like this
>>
>> entityManager.createQuery("FROM Order o", OrderDTO.class).getResultList()
>>
>> and get an optimal query, as well as objects with only the necessary
>> contents.
>>
>> Maybe we can collaborate on that somehow?
>>
>>
>> Mit freundlichen Grüßen,
>> 
>> *Christian Beikov*
>> Am 04.05.2017 um 10:20 schrieb Emmanuel Bernard:
>> > Following up a bit on my previous email.
>> >
>> > While a core integration might be best I think, if there are too much
>> > reluctance, we can start with a dedicated hibernate-dto or whatever
>> > module or even separate project that makes life easier for these "pass
>> > through" use cases. This could be in the form of a wrapper API of sort
>> > and hence not affect existing Hibernate ORM APIs.
>> >
>> > Note that the ResultTransformer approach feels like it goes a long way
>> > towards fixing the problem but as demonstrated in Vlad's article
>> >
>> https://vladmihalcea.com/2017/04/03/why-you-should-use-the-hibernate-resulttransformer-to-customize-result-set-mappings/
>> > it still requires quite a bit of code and a special DTO constructor
>> > object. That's what we need to get rid of I think.
>> >
>> > Emmanuel
>> >
>> > On Thu 17-05-04 10:04, Emmanuel Bernard wrote:
>> >> I was very much in the Vlad, Steve, Christian camp until relatively
>> >> recently. One of my main concern being that replacing a proxy by null
>> >> was really sending the wrong message. So I was against having Hibernate
>> >> ORM facilitate such a transformation.
>> >>
>> >> I am changing my mind because I am realizing that a lot of applications
>> >> are less complex that my perceived median. A lot of apps really just
>> >> want data to be fetched out and then passed to jackson (implicitly) and
>> >> pushed out as a REST response in JSON or some other serialization
>> >> protocol.
>> >>
>> >> So while we could try and keep the stance that such a solution should
>> >> remain out of scope of Hibernate ORM core, we should have a very smooth
>> >> integration with something like MapStruct to create 

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Steve Ebersole]

Were there a standard "represent something in XML-ish format" contract
portable across a number of formats (XML, JAXB, JSON, etc) then I'd be more
inclined to agree with this.  But as it is, supporting this would mean
Hibernate implementing multiple such contracts, one per format.  However,

   1. these formats are not our core competency
   2. maintaining a complete set of these transformers across all the
   popular formats du-jour is a large undertaking
   3. I am not convinced that

All of these increase the technical risk.

Additionally, to properly support this we'd really need the ability to then
"map" multiple views for a given entity-graph-root.  What I mean by that,
is that such DTO approaches often need multiple "views" of a given entity,
e.g. a CompanyListDTO, CompanyOverviewDTO, CompanyDetailsGeneralDTO, etc
for a Company entity.  The point of this is that

   1. the transformers for these are specific to each DTO type and would be
   applied per-transformation
   2. were Hibernate to "provide" this for applications

IMO the use of queries to obtain views is logical.  Populating each of
those specific DTOs (CompanyListDTO, etc) in the most efficient way is
going to require very different SQL for each DTO.  This implies some kind
of "mapping" to be able associate each DTO with query.

Given 6.0's improved dynamic-instantiation support, I even think that is a
great solution as well *for most cases*.

So, while my objection has a "practical impact" component, I also just
question whether Hibernate integrating with each format's "serializer" is
the proper solution.



On Thu, May 4, 2017 at 5:08 AM Christian Beikov 
wrote:

> This is exactly what I am trying to do with Blaze-Persistence Entity
> Views, making DTOs sexy and efficient :)
>
> Here a quick overview of how that looks like right now:
>
> https://persistence.blazebit.com/documentation/entity-view/manual/en_US/index.html#first-entity-view-query
>
> One of my targets is to make it possible to do something like this
>
> entityManager.createQuery("FROM Order o", OrderDTO.class).getResultList()
>
> and get an optimal query, as well as objects with only the necessary
> contents.
>
> Maybe we can collaborate on that somehow?
>
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> Am 04.05.2017 um 10:20 schrieb Emmanuel Bernard:
> > Following up a bit on my previous email.
> >
> > While a core integration might be best I think, if there are too much
> > reluctance, we can start with a dedicated hibernate-dto or whatever
> > module or even separate project that makes life easier for these "pass
> > through" use cases. This could be in the form of a wrapper API of sort
> > and hence not affect existing Hibernate ORM APIs.
> >
> > Note that the ResultTransformer approach feels like it goes a long way
> > towards fixing the problem but as demonstrated in Vlad's article
> >
> https://vladmihalcea.com/2017/04/03/why-you-should-use-the-hibernate-resulttransformer-to-customize-result-set-mappings/
> > it still requires quite a bit of code and a special DTO constructor
> > object. That's what we need to get rid of I think.
> >
> > Emmanuel
> >
> > On Thu 17-05-04 10:04, Emmanuel Bernard wrote:
> >> I was very much in the Vlad, Steve, Christian camp until relatively
> >> recently. One of my main concern being that replacing a proxy by null
> >> was really sending the wrong message. So I was against having Hibernate
> >> ORM facilitate such a transformation.
> >>
> >> I am changing my mind because I am realizing that a lot of applications
> >> are less complex that my perceived median. A lot of apps really just
> >> want data to be fetched out and then passed to jackson (implicitly) and
> >> pushed out as a REST response in JSON or some other serialization
> >> protocol.
> >>
> >> So while we could try and keep the stance that such a solution should
> >> remain out of scope of Hibernate ORM core, we should have a very smooth
> >> integration with something like MapStruct to create such bounded DTO on
> >> the fly. Ideally with as close to zero code as possible from the user
> >> point of view.
> >> I can't really describe how that could look like because I am not
> >> familiar enough with MapStruct but I think it should have the following
> >> characteristics:
> >>
> >> 1. do an implicit binding between the mapped object graph and a detached
> >>object graph with a 1-1 mapping of type and replacing lazy objects
> and
> >>collections with null. That's the smoothest approach and the most
> >>common use case but also the one where an inexperienced person could
> >>shoot at someone else's foot
> >> 2. do a binding between the mapped object graph and a detached version
> of
> >>that object graph with a 1-1 mapping of type, but declaratively
> >>expressing the boundaries for the detached version. This enforces a
> >>clear thinking of 

Re: [hibernate-dev] 6.0 - concept naming

[Chris Cranford]

Option 3.

On 05/03/2017 10:01 AM, Steve Ebersole wrote:
> To circle back to this... I mentioned possibly keeping a reference to the
> foreign-key defining the join predicate between the root table and the
> secondary table.  ATM however we do not model FKs in the runtime
> metamodel (either in 6 or before).  So that will not work unless we start
> to do that.
>
> Another possibility is to simply keep the list of columns from the
> secondary table that are used in the join predicate.  This would work
> because of an explicit rule followed by both Hibernate and JPA - namely
> that secondary tables (and joined inheritance tables btw) join back to the
> PK columns of the root table.  In other words, we implicitly know the "left
> hand side" portion of the join predicate.
>
> So we have 3 options total for modeling this join predicate:
>
>1. Maintain a predicate tree as part of this SecondaryTableBinding.  ATM
>we have no such concept of this either in the runtime metamodel, so we
>would need to add this if we choose this option.  This would mean adding
>the concept of conjunction/disjunction and relational-operators in some
>form to the runtime metamodel.  Personally, this is my least favorite
>option.
>2. Maintain the join predicate on SecondaryTableBinding via a FK
>reference.  Again, this would mean adding a new concept/class to model the
>FK as part of the runtime metamodel.  I am not against this option so long
>as we deem it has similar benefits in other parts of the codebase - I'd
>prefer to not add such a concept just to handle this case.
>3. Follow the assumption regarding the "left hand side" of these joins
>and just keep a list of the columns from the secondary table that link to
>the entity's root table's PK columns.
>
>
> FWIW, both Hibernate and JPA also assume that the same holds true for
> joined inheritance tables.  Whatever we decide here for secondary tables,
> we should apply to modeling joined inheritence for consistency - perhaps
> even to the point of a shared contract (NonRootTableBinding?).
>
> Opinions?
>
> On Wed, Apr 19, 2017 at 8:35 AM Steve Ebersole  wrote:
>
>> On Wed, Apr 19, 2017 at 6:00 AM Christian Beikov <
>> christian.bei...@gmail.com> wrote:
>>
>>> Sounds good. I hope the secondary table stuff is getting defined on a
>>> higher level(EntityPersister/AbstractEntityPersister). I had problems
>>> implementing OneToOne-JoinTable support for
>>> TablePerClass(UnionSubclassPersister) a while ago and I guess that was
>>> because there is no notion of secondary tables in the EntityPersister. I
>>> guess that issue would be solved then? :)
>>>
>> Not sure what you mean by "higher level".  The design here specifically
>> shows secondary tables modeled as top-level concepts (
>> SecondaryTableBinding).  So I think, again iiuc, that the design already
>> shows secondary tables "defined on a higher level".
>>
> ___
> 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] [feature request][discuss] smoother serializers integration?

[Christian Beikov]

This is exactly what I am trying to do with Blaze-Persistence Entity 
Views, making DTOs sexy and efficient :)

Here a quick overview of how that looks like right now: 
https://persistence.blazebit.com/documentation/entity-view/manual/en_US/index.html#first-entity-view-query

One of my targets is to make it possible to do something like this

entityManager.createQuery("FROM Order o", OrderDTO.class).getResultList()

and get an optimal query, as well as objects with only the necessary 
contents.

Maybe we can collaborate on that somehow?


Mit freundlichen Grüßen,

*Christian Beikov*
Am 04.05.2017 um 10:20 schrieb Emmanuel Bernard:
> Following up a bit on my previous email.
>
> While a core integration might be best I think, if there are too much
> reluctance, we can start with a dedicated hibernate-dto or whatever
> module or even separate project that makes life easier for these "pass
> through" use cases. This could be in the form of a wrapper API of sort
> and hence not affect existing Hibernate ORM APIs.
>
> Note that the ResultTransformer approach feels like it goes a long way
> towards fixing the problem but as demonstrated in Vlad's article
> https://vladmihalcea.com/2017/04/03/why-you-should-use-the-hibernate-resulttransformer-to-customize-result-set-mappings/
> it still requires quite a bit of code and a special DTO constructor
> object. That's what we need to get rid of I think.
>
> Emmanuel
>
> On Thu 17-05-04 10:04, Emmanuel Bernard wrote:
>> I was very much in the Vlad, Steve, Christian camp until relatively
>> recently. One of my main concern being that replacing a proxy by null
>> was really sending the wrong message. So I was against having Hibernate
>> ORM facilitate such a transformation.
>>
>> I am changing my mind because I am realizing that a lot of applications
>> are less complex that my perceived median. A lot of apps really just
>> want data to be fetched out and then passed to jackson (implicitly) and
>> pushed out as a REST response in JSON or some other serialization
>> protocol.
>>
>> So while we could try and keep the stance that such a solution should
>> remain out of scope of Hibernate ORM core, we should have a very smooth
>> integration with something like MapStruct to create such bounded DTO on
>> the fly. Ideally with as close to zero code as possible from the user
>> point of view.
>> I can't really describe how that could look like because I am not
>> familiar enough with MapStruct but I think it should have the following
>> characteristics:
>>
>> 1. do an implicit binding between the mapped object graph and a detached
>>object graph with a 1-1 mapping of type and replacing lazy objects and
>>collections with null. That's the smoothest approach and the most
>>common use case but also the one where an inexperienced person could
>>shoot at someone else's foot
>> 2. do a binding between the mapped object graph and a detached version of
>>that object graph with a 1-1 mapping of type, but declaratively
>>expressing the boundaries for the detached version. This enforces a
>>clear thinking of the boundaries and will load lazy data in case the
>>object graph loaded is missing a bit. I like the idea on principle but
>>I think it overlaps a lot with the fetch graph.
>> 3. offer a full integration between MapStruct and Hibernate ORM by
>>letting people express a full fledge MapStruct transformation between
>>the managed object graph and a different target structure
>>
>> I favored MapStruct over Dozer because we know the MapStruct lead quite well 
>> ;)
>>
>> Note however that the MapStruct approach requires an explicit object
>> copy, it feels a bit sad to have to double memory consumption. But that
>> might be a good enough approach and bypassing the managed object
>> creation leads to questions around the Persistence Context contract
>> where loading an object supposedly means it will be in the PC.
>> Maybe a constructor like query syntax allowing to reference a MapStruct
>> conversion logic might work?
>>
>> select mapStruct('order-and-items', o) from Order o left join fetch 
>> o.items
>>
>> Emmanuel
>>
>>
>> On Wed 17-04-19 14:29, Vlad Mihalcea wrote:
>>> Hi,
>>>
>>> Although I keep on seeing this request from time to time, I still think
>>> it's more like a Code Smell.
>>> Entities are useful for when you plan to modify them. Otherwise, a DTO
>>> projection is much more efficient, and you don't suffer from
>>> LazyInitializationException.
>>>
>>> With the ResultTransformer, you can even build graphs of entities, as
>>> explained in this article;
>>>
>>> https://vladmihalcea.com/2017/04/03/why-you-should-use-the-hibernate-resulttransformer-to-customize-result-set-mappings/
>>>
>>> Due to how Hibernate Proxies are handled, without Bytecode Enhancement,
>>> it's difficult to replace a Proxy with null after the Session is closed. If
>>> we implemented this, 

Re: [hibernate-dev] 6.0 - concept naming

[Christian Beikov]

Hehe too fast, I meant option 3. :D


Mit freundlichen Grüßen,

*Christian Beikov*
Am 03.05.2017 um 16:01 schrieb Steve Ebersole:
> To circle back to this... I mentioned possibly keeping a reference to 
> the foreign-key defining the join predicate between the root table and 
> the secondary table.  ATM however we do not model FKs in the runtime 
> metamodel (either in 6 or before).  So that will not work unless we 
> start to do that.
>
> Another possibility is to simply keep the list of columns from the 
> secondary table that are used in the join predicate. This would work 
> because of an explicit rule followed by both Hibernate and JPA - 
> namely that secondary tables (and joined inheritance tables btw) join 
> back to the PK columns of the root table.  In other words, we 
> implicitly know the "left hand side" portion of the join predicate.
>
> So we have 3 options total for modeling this join predicate:
>
>  1. Maintain a predicate tree as part of this SecondaryTableBinding. 
> ATM we have no such concept of this either in the runtime
> metamodel, so we would need to add this if we choose this option. 
> This would mean adding the concept of conjunction/disjunction and
> relational-operators in some form to the runtime metamodel. 
> Personally, this is my least favorite option.
>  2. Maintain the join predicate on SecondaryTableBinding via a FK
> reference.  Again, this would mean adding a new concept/class to
> model the FK as part of the runtime metamodel.  I am not against
> this option so long as we deem it has similar benefits in other
> parts of the codebase - I'd prefer to not add such a concept just
> to handle this case.
>  3. Follow the assumption regarding the "left hand side" of these
> joins and just keep a list of the columns from the secondary table
> that link to the entity's root table's PK columns.
>
>
> FWIW, both Hibernate and JPA also assume that the same holds true for 
> joined inheritance tables.  Whatever we decide here for secondary 
> tables, we should apply to modeling joined inheritence for consistency 
> - perhaps even to the point of a shared contract (NonRootTableBinding?).
>
> Opinions?
>
> On Wed, Apr 19, 2017 at 8:35 AM Steve Ebersole  > wrote:
>
> On Wed, Apr 19, 2017 at 6:00 AM Christian Beikov
> >
> wrote:
>
> Sounds good. I hope the secondary table stuff is getting
> defined on a
> higher level(EntityPersister/AbstractEntityPersister). I had
> problems
> implementing OneToOne-JoinTable support for
> TablePerClass(UnionSubclassPersister) a while ago and I guess
> that was
> because there is no notion of secondary tables in the
> EntityPersister. I
> guess that issue would be solved then? :)
>
>
> Not sure what you mean by "higher level".  The design here
> specifically shows secondary tables modeled as top-level concepts
> (SecondaryTableBinding). So I think, again iiuc, that the design
> already shows secondary tables "defined on a higher level".
>

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - concept naming

[Christian Beikov]

Option 1 sounds good.


Mit freundlichen Grüßen,

*Christian Beikov*
Am 03.05.2017 um 16:01 schrieb Steve Ebersole:
> To circle back to this... I mentioned possibly keeping a reference to 
> the foreign-key defining the join predicate between the root table and 
> the secondary table.  ATM however we do not model FKs in the runtime 
> metamodel (either in 6 or before).  So that will not work unless we 
> start to do that.
>
> Another possibility is to simply keep the list of columns from the 
> secondary table that are used in the join predicate. This would work 
> because of an explicit rule followed by both Hibernate and JPA - 
> namely that secondary tables (and joined inheritance tables btw) join 
> back to the PK columns of the root table.  In other words, we 
> implicitly know the "left hand side" portion of the join predicate.
>
> So we have 3 options total for modeling this join predicate:
>
>  1. Maintain a predicate tree as part of this SecondaryTableBinding. 
> ATM we have no such concept of this either in the runtime
> metamodel, so we would need to add this if we choose this option. 
> This would mean adding the concept of conjunction/disjunction and
> relational-operators in some form to the runtime metamodel. 
> Personally, this is my least favorite option.
>  2. Maintain the join predicate on SecondaryTableBinding via a FK
> reference.  Again, this would mean adding a new concept/class to
> model the FK as part of the runtime metamodel.  I am not against
> this option so long as we deem it has similar benefits in other
> parts of the codebase - I'd prefer to not add such a concept just
> to handle this case.
>  3. Follow the assumption regarding the "left hand side" of these
> joins and just keep a list of the columns from the secondary table
> that link to the entity's root table's PK columns.
>
>
> FWIW, both Hibernate and JPA also assume that the same holds true for 
> joined inheritance tables.  Whatever we decide here for secondary 
> tables, we should apply to modeling joined inheritence for consistency 
> - perhaps even to the point of a shared contract (NonRootTableBinding?).
>
> Opinions?
>
> On Wed, Apr 19, 2017 at 8:35 AM Steve Ebersole  > wrote:
>
> On Wed, Apr 19, 2017 at 6:00 AM Christian Beikov
> >
> wrote:
>
> Sounds good. I hope the secondary table stuff is getting
> defined on a
> higher level(EntityPersister/AbstractEntityPersister). I had
> problems
> implementing OneToOne-JoinTable support for
> TablePerClass(UnionSubclassPersister) a while ago and I guess
> that was
> because there is no notion of secondary tables in the
> EntityPersister. I
> guess that issue would be solved then? :)
>
>
> Not sure what you mean by "higher level".  The design here
> specifically shows secondary tables modeled as top-level concepts
> (SecondaryTableBinding). So I think, again iiuc, that the design
> already shows secondary tables "defined on a higher level".
>

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Emmanuel Bernard]

Following up a bit on my previous email.

While a core integration might be best I think, if there are too much
reluctance, we can start with a dedicated hibernate-dto or whatever
module or even separate project that makes life easier for these "pass
through" use cases. This could be in the form of a wrapper API of sort
and hence not affect existing Hibernate ORM APIs.

Note that the ResultTransformer approach feels like it goes a long way
towards fixing the problem but as demonstrated in Vlad's article
https://vladmihalcea.com/2017/04/03/why-you-should-use-the-hibernate-resulttransformer-to-customize-result-set-mappings/
it still requires quite a bit of code and a special DTO constructor
object. That's what we need to get rid of I think.

Emmanuel

On Thu 17-05-04 10:04, Emmanuel Bernard wrote:
>I was very much in the Vlad, Steve, Christian camp until relatively
>recently. One of my main concern being that replacing a proxy by null
>was really sending the wrong message. So I was against having Hibernate
>ORM facilitate such a transformation.
>
>I am changing my mind because I am realizing that a lot of applications
>are less complex that my perceived median. A lot of apps really just
>want data to be fetched out and then passed to jackson (implicitly) and
>pushed out as a REST response in JSON or some other serialization
>protocol.
>
>So while we could try and keep the stance that such a solution should
>remain out of scope of Hibernate ORM core, we should have a very smooth
>integration with something like MapStruct to create such bounded DTO on
>the fly. Ideally with as close to zero code as possible from the user
>point of view.
>I can't really describe how that could look like because I am not
>familiar enough with MapStruct but I think it should have the following
>characteristics:
>
>1. do an implicit binding between the mapped object graph and a detached
>   object graph with a 1-1 mapping of type and replacing lazy objects and
>   collections with null. That's the smoothest approach and the most
>   common use case but also the one where an inexperienced person could
>   shoot at someone else's foot
>2. do a binding between the mapped object graph and a detached version of
>   that object graph with a 1-1 mapping of type, but declaratively
>   expressing the boundaries for the detached version. This enforces a
>   clear thinking of the boundaries and will load lazy data in case the
>   object graph loaded is missing a bit. I like the idea on principle but
>   I think it overlaps a lot with the fetch graph.
>3. offer a full integration between MapStruct and Hibernate ORM by
>   letting people express a full fledge MapStruct transformation between
>   the managed object graph and a different target structure
>
>I favored MapStruct over Dozer because we know the MapStruct lead quite well ;)
>
>Note however that the MapStruct approach requires an explicit object
>copy, it feels a bit sad to have to double memory consumption. But that
>might be a good enough approach and bypassing the managed object
>creation leads to questions around the Persistence Context contract
>where loading an object supposedly means it will be in the PC.
>Maybe a constructor like query syntax allowing to reference a MapStruct
>conversion logic might work?
>
>select mapStruct('order-and-items', o) from Order o left join fetch o.items
>
>Emmanuel
>
>
>On Wed 17-04-19 14:29, Vlad Mihalcea wrote:
>>Hi,
>>
>>Although I keep on seeing this request from time to time, I still think
>>it's more like a Code Smell.
>>Entities are useful for when you plan to modify them. Otherwise, a DTO
>>projection is much more efficient, and you don't suffer from
>>LazyInitializationException.
>>
>>With the ResultTransformer, you can even build graphs of entities, as
>>explained in this article;
>>
>>https://vladmihalcea.com/2017/04/03/why-you-should-use-the-hibernate-resulttransformer-to-customize-result-set-mappings/
>>
>>Due to how Hibernate Proxies are handled, without Bytecode Enhancement,
>>it's difficult to replace a Proxy with null after the Session is closed. If
>>we implemented this, we'd have to take into consideration both Javassist
>>and ByteBuddy as well as ByteCode Enhancements.
>>
>>all in all, the implementation effort might not justify the benefit, and
>>I'm skeptical of offering a feature that does not encourage data access
>>Best Practices.
>>
>>Vlad
>>
>>On Wed, Apr 19, 2017 at 2:18 PM, Christian Beikov <
>>christian.bei...@gmail.com> wrote:
>>
>>> Hey Romain,
>>>
>>> I don't think it is a good idea to expose entities directly if you
>>> really need a subset of the data.
>>> Reasons for that thinking are that it gets hard to define what needs to
>>> be fetched or is safe to be used for a particular use case. Obviously
>>> serialization is like a follow-up problem.
>>> I see 2 possible solutions to the problem and both boil down to the use
>>> of DTOs.
>>>
>>>  1. Use an object mapper(e.g. Dozer) that maps entity object graphs 

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Romain Manni-Bucau]

For now I integrated it with johnzon:

@Provider
public class ApiHibernateJsonbProvider extends JsonbJaxrsProvider {
@Override
protected Jsonb createJsonb() {
return JsonbProvider.provider().create()
.withConfig(new JsonbConfig()
.setProperty("johnzon.serialize-value-filter",
(SerializeValueFilter) this::shouldIgnoreField))
.build();
}

private boolean shouldIgnoreField(final String
ignoredPropertyName, final Object value) {
return (HibernateProxy.class.isInstance(value) &&
HibernateProxy.class.cast(value).getHibernateLazyInitializer().isUninitialized())
||
PersistentCollection.class.isInstance(value) &&
!PersistentCollection.class.cast(value).wasInitialized();
}
}


So maybe an utility allowing to just integrate with any serializer (which
already browse the model) would be smoother than a specific integration. I
also think spring (and its trendy boot flavor) does that kind of thing
through spring-data-rest.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-05-04 10:04 GMT+02:00 Emmanuel Bernard :

> I was very much in the Vlad, Steve, Christian camp until relatively
> recently. One of my main concern being that replacing a proxy by null
> was really sending the wrong message. So I was against having Hibernate
> ORM facilitate such a transformation.
>
> I am changing my mind because I am realizing that a lot of applications
> are less complex that my perceived median. A lot of apps really just
> want data to be fetched out and then passed to jackson (implicitly) and
> pushed out as a REST response in JSON or some other serialization
> protocol.
>
> So while we could try and keep the stance that such a solution should
> remain out of scope of Hibernate ORM core, we should have a very smooth
> integration with something like MapStruct to create such bounded DTO on
> the fly. Ideally with as close to zero code as possible from the user
> point of view.
> I can't really describe how that could look like because I am not
> familiar enough with MapStruct but I think it should have the following
> characteristics:
>
> 1. do an implicit binding between the mapped object graph and a detached
>object graph with a 1-1 mapping of type and replacing lazy objects and
>collections with null. That's the smoothest approach and the most
>common use case but also the one where an inexperienced person could
>shoot at someone else's foot
> 2. do a binding between the mapped object graph and a detached version of
>that object graph with a 1-1 mapping of type, but declaratively
>expressing the boundaries for the detached version. This enforces a
>clear thinking of the boundaries and will load lazy data in case the
>object graph loaded is missing a bit. I like the idea on principle but
>I think it overlaps a lot with the fetch graph.
> 3. offer a full integration between MapStruct and Hibernate ORM by
>letting people express a full fledge MapStruct transformation between
>the managed object graph and a different target structure
>
> I favored MapStruct over Dozer because we know the MapStruct lead quite
> well ;)
>
> Note however that the MapStruct approach requires an explicit object
> copy, it feels a bit sad to have to double memory consumption. But that
> might be a good enough approach and bypassing the managed object
> creation leads to questions around the Persistence Context contract
> where loading an object supposedly means it will be in the PC.
> Maybe a constructor like query syntax allowing to reference a MapStruct
> conversion logic might work?
>
> select mapStruct('order-and-items', o) from Order o left join fetch
> o.items
>
> Emmanuel
>
>
> On Wed 17-04-19 14:29, Vlad Mihalcea wrote:
> >Hi,
> >
> >Although I keep on seeing this request from time to time, I still think
> >it's more like a Code Smell.
> >Entities are useful for when you plan to modify them. Otherwise, a DTO
> >projection is much more efficient, and you don't suffer from
> >LazyInitializationException.
> >
> >With the ResultTransformer, you can even build graphs of entities, as
> >explained in this article;
> >
> >https://vladmihalcea.com/2017/04/03/why-you-should-use-the-hibernate-
> resulttransformer-to-customize-result-set-mappings/
> >
> >Due to how Hibernate Proxies are handled, without Bytecode Enhancement,
> >it's difficult to replace a Proxy with null after the Session is closed.
> If
> >we implemented this, we'd have to take into consideration both Javassist
> >and ByteBuddy as well as ByteCode Enhancements.
> >
> >all in all, the implementation effort might not justify the benefit, and
> 

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

[Emmanuel Bernard]

I was very much in the Vlad, Steve, Christian camp until relatively
recently. One of my main concern being that replacing a proxy by null
was really sending the wrong message. So I was against having Hibernate
ORM facilitate such a transformation.

I am changing my mind because I am realizing that a lot of applications
are less complex that my perceived median. A lot of apps really just
want data to be fetched out and then passed to jackson (implicitly) and
pushed out as a REST response in JSON or some other serialization
protocol.

So while we could try and keep the stance that such a solution should
remain out of scope of Hibernate ORM core, we should have a very smooth
integration with something like MapStruct to create such bounded DTO on
the fly. Ideally with as close to zero code as possible from the user
point of view.
I can't really describe how that could look like because I am not
familiar enough with MapStruct but I think it should have the following
characteristics:

1. do an implicit binding between the mapped object graph and a detached
   object graph with a 1-1 mapping of type and replacing lazy objects and
   collections with null. That's the smoothest approach and the most
   common use case but also the one where an inexperienced person could
   shoot at someone else's foot
2. do a binding between the mapped object graph and a detached version of
   that object graph with a 1-1 mapping of type, but declaratively
   expressing the boundaries for the detached version. This enforces a
   clear thinking of the boundaries and will load lazy data in case the
   object graph loaded is missing a bit. I like the idea on principle but
   I think it overlaps a lot with the fetch graph.
3. offer a full integration between MapStruct and Hibernate ORM by
   letting people express a full fledge MapStruct transformation between
   the managed object graph and a different target structure

I favored MapStruct over Dozer because we know the MapStruct lead quite well ;)

Note however that the MapStruct approach requires an explicit object
copy, it feels a bit sad to have to double memory consumption. But that
might be a good enough approach and bypassing the managed object
creation leads to questions around the Persistence Context contract
where loading an object supposedly means it will be in the PC.
Maybe a constructor like query syntax allowing to reference a MapStruct
conversion logic might work?

select mapStruct('order-and-items', o) from Order o left join fetch o.items

Emmanuel


On Wed 17-04-19 14:29, Vlad Mihalcea wrote:
>Hi,
>
>Although I keep on seeing this request from time to time, I still think
>it's more like a Code Smell.
>Entities are useful for when you plan to modify them. Otherwise, a DTO
>projection is much more efficient, and you don't suffer from
>LazyInitializationException.
>
>With the ResultTransformer, you can even build graphs of entities, as
>explained in this article;
>
>https://vladmihalcea.com/2017/04/03/why-you-should-use-the-hibernate-resulttransformer-to-customize-result-set-mappings/
>
>Due to how Hibernate Proxies are handled, without Bytecode Enhancement,
>it's difficult to replace a Proxy with null after the Session is closed. If
>we implemented this, we'd have to take into consideration both Javassist
>and ByteBuddy as well as ByteCode Enhancements.
>
>all in all, the implementation effort might not justify the benefit, and
>I'm skeptical of offering a feature that does not encourage data access
>Best Practices.
>
>Vlad
>
>On Wed, Apr 19, 2017 at 2:18 PM, Christian Beikov <
>christian.bei...@gmail.com> wrote:
>
>> Hey Romain,
>>
>> I don't think it is a good idea to expose entities directly if you
>> really need a subset of the data.
>> Reasons for that thinking are that it gets hard to define what needs to
>> be fetched or is safe to be used for a particular use case. Obviously
>> serialization is like a follow-up problem.
>> I see 2 possible solutions to the problem and both boil down to the use
>> of DTOs.
>>
>>  1. Use an object mapper(e.g. Dozer) that maps entity object graphs to
>> custom DTO types.
>>  2. Use specialized DTOs in queries.
>>
>>
>> Implementing 1. does not help you with lazy loading issues and 2. might
>> require very intrusive changes in queries which is why I implemented
>> Blaze-Persistence Entity Views
>> .
>> This is a library that allows you to define DTOs with mappings to the
>> entity. In a query you can define that you want results to be
>> "materialized" as instances of the DTO type.
>> This reduces the pain induced by properly separating the "presentation
>> model" from the "persistence model" and at the same time will improve
>> the performance by utilizing the mapping information.
>> I don't want to advertise too much, just wanted to say that I had the
>> same issues over and over which is why I started that project.
>>
>> Mit freundlichen Grüßen,
>>