But your psuedo code is really just the same as: AnEntity e = find(); if ( isInitialized( e ) ) { serializer.serialize(e); }
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. On Thu, May 4, 2017 at 11:46 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > 2017-05-04 18:42 GMT+02:00 Christian Beikov <christian.bei...@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 <st...@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.bei...@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.bei...@gmail.com <mailto:christian.bei...@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" <st...@hibernate.org >>> > >> <mailto:st...@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 >>> > >> <st...@hibernate.org <mailto:st...@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.bei...@gmail.com >>> > >> <mailto:christian.bei...@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.bei...@gmail.com >>> > >> <mailto:christian.bei...@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@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@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@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@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@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@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@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@lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> >> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev