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

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 <rmannibucau(a)gmail.com&gt; wrote: > 2017-05-04 19:16 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> 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(a)gmail.com&gt; wrote: >> >>> 2017-05-04 18:42 GMT+02:00 Christian Beikov <christian.beikov(a)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(a)hibernate.org&gt;: >>>> >>>>> 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(a)gmail.com&gt; >>>>> 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(a)gmail.com <mailto:christian.beikov@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(a)hibernate.org >>>>> > >> <mailto:steve@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(a)hibernate.org <mailto:steve@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(a)gmail.com >>>>> > >> <mailto:christian.beikov@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/i... >>>>> > >> < >>>>> > >>>>> https://persistence.blazebit.com/documentation/entity-view/manual/en_US/i... >>>>> > > >>>>> > >> >> >>>>> > >> >> 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-resu... >>>>> > >> < >>>>> > >>>>> https://vladmihalcea.com/2017/04/03/why-you-should-use-the-hibernate-resu... >>>>> > > >>>>> > >> >> > 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-resu... >>>>> > >> < >>>>> > >>>>> 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 >>>>> > >> <mailto:christian.beikov@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(a)lists.jboss.org >>>>> > >> <mailto:hibernate-dev@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(a)lists.jboss.org >>>>> > >> <mailto:hibernate-dev@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(a)lists.jboss.org >>>>> > >> <mailto:hibernate-dev@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(a)lists.jboss.org >>>>> > >> <mailto:hibernate-dev@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(a)lists.jboss.org >>>>> > >> <mailto:hibernate-dev@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(a)lists.jboss.org >>>>> > >> <mailto:hibernate-dev@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(a)lists.jboss.org >>>>> > >> <mailto:hibernate-dev@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(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 >>>>> >>>> >>>> >>>>