[hibernate-dev] [feature request][discuss] smoother serializers integration?
Romain Manni-Bucau
rmannibucau at gmail.com
Thu May 4 13:18:04 EDT 2017
2017-05-04 19:16 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> 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 <rmannibucau at gmail.com>
> wrote:
>
>> 2017-05-04 18:42 GMT+02:00 Christian Beikov <christian.beikov at 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 <steve at hibernate.org>:
>>>
>>>> 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.beikov at 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<String> 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
>>>> > > <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>:
>>>> > >
>>>> > > 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" <steve at hibernate.org
>>>> > >> <mailto:steve at hibernate.org>> 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
>>>> > >> <steve at hibernate.org <mailto:steve at hibernate.org>> 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.beikov at gmail.com
>>>> > >> <mailto:christian.beikov at 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
>>>> > >> <
>>>> > 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/
>>>> > >> <
>>>> > 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/
>>>> > >> <
>>>> > 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.beikov at gmail.com
>>>> > >> <mailto:christian.beikov at 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
>>>> > >> <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
>>>> > >> <https://twitter.com/rmannibucau>> | Blog
>>>> > >> >> >>>>> <https://blog-rmannibucau.rhcloud.com
>>>> > >> <https://blog-rmannibucau.rhcloud.com>> | Old Blog
>>>> > >> >> >>>>> <http://rmannibucau.wordpress.com
>>>> > >> <http://rmannibucau.wordpress.com>> | Github <
>>>> > https://github.com/
>>>> > >> >> >>>> rmannibucau> |
>>>> > >> >> >>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau
>>>> > >> <https://www.linkedin.com/in/rmannibucau>> | JavaEE
>>>> Factory
>>>> > >> >> >>>>> <https://javaeefactory-rmannibucau.rhcloud.com
>>>> > >> <https://javaeefactory-rmannibucau.rhcloud.com>>
>>>> > >> >> >>>>> _______________________________________________
>>>> > >> >> >>>>> hibernate-dev mailing list
>>>> > >> >> >>>>> hibernate-dev at lists.jboss.org
>>>> > >> <mailto:hibernate-dev at lists.jboss.org>
>>>> > >> >> >>>>>
>>>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> > >> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>> > >> >> >>>> _______________________________________________
>>>> > >> >> >>>> hibernate-dev mailing list
>>>> > >> >> >>>> hibernate-dev at lists.jboss.org
>>>> > >> <mailto:hibernate-dev at lists.jboss.org>
>>>> > >> >> >>>>
>>>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> > >> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>> > >> >> >>>>
>>>> > >> >> >>> _______________________________________________
>>>> > >> >> >>> hibernate-dev mailing list
>>>> > >> >> >>> hibernate-dev at lists.jboss.org
>>>> > >> <mailto:hibernate-dev at lists.jboss.org>
>>>> > >> >> >>> https://lists.jboss.org/
>>>> mailman/listinfo/hibernate-dev
>>>> > >> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>> > >> >> >> _______________________________________________
>>>> > >> >> >> hibernate-dev mailing list
>>>> > >> >> >> hibernate-dev at lists.jboss.org
>>>> > >> <mailto:hibernate-dev at lists.jboss.org>
>>>> > >> >> >> https://lists.jboss.org/
>>>> mailman/listinfo/hibernate-dev
>>>> > >> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>> > >> >> > _______________________________________________
>>>> > >> >> > hibernate-dev mailing list
>>>> > >> >> > hibernate-dev at lists.jboss.org
>>>> > >> <mailto:hibernate-dev at lists.jboss.org>
>>>> > >> >> > https://lists.jboss.org/
>>>> mailman/listinfo/hibernate-dev
>>>> > >> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>> > >> >>
>>>> > >> >> _______________________________________________
>>>> > >> >> hibernate-dev mailing list
>>>> > >> >> hibernate-dev at lists.jboss.org
>>>> > >> <mailto:hibernate-dev at lists.jboss.org>
>>>> > >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> > >> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>> > >> >>
>>>> > >> >
>>>> > >> _______________________________________________
>>>> > >> hibernate-dev mailing list
>>>> > >> hibernate-dev at lists.jboss.org
>>>> > >> <mailto:hibernate-dev at lists.jboss.org>
>>>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> > >> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>> > >>
>>>> > >
>>>> > >
>>>> >
>>>> > _______________________________________________
>>>> > hibernate-dev mailing list
>>>> > hibernate-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>>>
More information about the hibernate-dev
mailing list