3:04 a.m.
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-resu...
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.beikov(a)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
> <https://github.com/beikov/blaze-persistence#entity-view-usage>;.
> 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,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 19.04.2017 um 10:51 schrieb Romain Manni-Bucau:
> > 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 directly
> > hibernate entities (which is more and more common with microservice
> > "movement").
> >
> > Objective: the goal is to not need any step - or reduce them a lot -
> > between the hibernate interaction and a potential serialization to avoid
> > issues with lazy loading and unexpected loading. Today it requires some
> > custom and hibernate specific logic in the serializer which kind of
> breaks
> > the transversality of the two concerns (serialization and object
> > management/loading).
> >
> >
> > Implementation options I see:
> >
> > 1. a callback requesting if the lazy relationship should be fetched,
> > something like
> >
> > public interface GraphVisitor {
> > boolean shouldLoad(Object rootEntity, Property property);
> > }
> >
> > 2. An utility to remove any proxy potentially throwing an exception and
> > replacing the value by null or an empty collection, something like
> >
> > MyEntity e = Hibernate.deepUnproxy(entity);
> >
> > 3. A switch of the proxy implementation, this is close to 2 but wouldn't
> > require a call to any utility, just a configuration in the persistence
> unit.
> >
> > Side note: of course all 3 options can be mixed to create a single
> solution
> > like having 3 implemented based on 1 for instance.
> >
> > Configuration proposal: this would be activated through a property in the
> > persistence unit (this shouldn't be only global IMHO cause otherwise you
> > can't mix 2 kind of units, like one for JSF and one for JAX-RS to be
> > concrete). This should also be activable as a query hint i think - but
> more
> > a nice to have.
> >
> >
> > What this feature wouldn't be responsible for: cycles. If relationships
> are
> > bidirectional then the unproxied entity would still "loop" if you
browse
> > the object graph - this responsability would stay in the consumer since
> it
> > doesn't depend on hibernate directly but more on a plain object handling.
> >
> > What do you think?
> >
> >
> > Romain Manni-Bucau
> > @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> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev