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

[Christian Beikov]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev