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

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&gt; >> : >> >>> 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 >>>> >>> >>> >>>