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
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(
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
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 pr
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 defini
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 t
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 o
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.
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
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
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 d
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
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
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
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 wil
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 mak
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,
> attributeNam
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 b
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 isIni
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 psued
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
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
fo
22 matches
Mail list logo
