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
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
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
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
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 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
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 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
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
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
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
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
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
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
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.
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
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
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(
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
This was actually the intent of the original introduction of EntityMode and
specifically the DOM4J EntityMode. But that stuff was deemed "outside the
scope" of Hibernate proper.
As others have stated in reply, I think this is really best served by a
use-case-specific combination of dynamic fetch
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau
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
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 proble
Hi guys,
Short sumarry: Wonder if hibernate could get a feature to kind of either
unproxy or freeze the entities once leaving the managed context to avoid
uncontrolled lazy loading on one side and serialization issues on another
side.
Use case example: a common example is a REST service exposing
24 matches
Mail list logo
