Re: [hibernate-dev] 6.0 - ResultTransformer

On Tue, Sep 13, 2016 at 9:55 PM Gail Badner wrote: > Sorry for the late response. I've been looking through the fix for > HHH-5163 [1] to jog my memory. > > Here are some reasons why CacheableResultTransformer is important when > caching query results: > > 1) The same SQL can

Re: [hibernate-dev] 6.0 - ResultTransformer

Sorry for the late response. I've been looking through the fix for HHH-5163 [1] to jog my memory. Here are some reasons why CacheableResultTransformer is important when caching query results: 1) The same SQL can be generated when associations are joined as when associations are fetched, but what

Re: [hibernate-dev] 6.0 - ResultTransformer

BTW... https://hibernate.atlassian.net/browse/HHH-11104 On Tue, Sep 13, 2016 at 7:05 PM Steve Ebersole wrote: > Hmmm there is an interesting aspect to Tuple + TupleTransformer.. both > expect to get the root selection aliases and would naturally expect those > to match in

Re: [hibernate-dev] 6.0 - ResultTransformer

Hmmm there is an interesting aspect to Tuple + TupleTransformer.. both expect to get the root selection aliases and would naturally expect those to match in length to the values to transform. Basically only one can "consume" the aliases. I think that because Tuple is a "higher precedence" (it

Re: [hibernate-dev] 6.0 - ResultTransformer

So here is the path I am following initially.. It is straightforward to explain to a user which I like. In terms of processing each "row" in a result there is the RowTransformer contract I mentioned earlier, or maybe I mentioned on HipChat. I added the capability for RowTransformer to be nested,

Re: [hibernate-dev] 6.0 - ResultTransformer

So again, this all boils down to the interplay with (Result|Tuple|ResultList)Transformer, dynamic instantiations, and result-types. So let's look at some specific cases... First some cases I think are perfectly valid: session.createQuery( "select new map(...) ...", Map.class ) - returns a

Re: [hibernate-dev] 6.0 - ResultTransformer

On Tue, Sep 13, 2016 at 5:23 AM Emmanuel Bernard wrote: > My preference would be to keep some form of resultTransformer around, > especially the first method that is redundant. > > And it's mainly because it is very easy to write one and plug. The HQL > based

Re: [hibernate-dev] 6.0 - ResultTransformer

On Tue, Sep 13, 2016 at 2:26 AM Gunnar Morling wrote: > > Between dynamic-instantiation, Tuple-handling... > > To be sure, WDYM by "tuple-handling"? > javax.persistence.Tuple So I gave just one example earlier of how all of these things do not necessarily fit together in

Re: [hibernate-dev] 6.0 - ResultTransformer

My preference would be to keep some form of resultTransformer around, especially the first method that is redundant. And it's mainly because it is very easy to write one and plug. The HQL based instantiation is fine when you use it but as Gunnar mentioned, this is not always the case. What is the

Re: [hibernate-dev] 6.0 - ResultTransformer

> Between dynamic-instantiation, Tuple-handling... To be sure, WDYM by "tuple-handling"? One use case for result transformers are full-text searches executed through Hibernate Search's Session extension FullTextSession (see [1]). For full-text searches we don't use HQL/JPQL, so the "new ..."

Re: [hibernate-dev] 6.0 - ResultTransformer

I'd say one can either use the "new .." syntax, or a ResultTransformer/TupleTransformer but not both at the same time. IMO you can do your DTO stuff in the transformer which is probably also one of the few usecases for ResultTransformer. Am 13.09.2016 um 01:33 schrieb Steve Ebersole: > If we

Re: [hibernate-dev] 6.0 - ResultTransformer

If we are going to support #transformTuple (in whatever form) we need to decide on a precedence between that, resultClass, dynamic-instantiation, etc Specifically, what is the meaning of: session.createQuery( "select new DTO(...) ...", DTO.class ) .setTupleTransformer( () -> ... )

Re: [hibernate-dev] 6.0 - ResultTransformer

Gail, IIRC one of these methods causes problems with regards to query result caching. Do I remember that correctly? And if so, do you remember which one? I'd guess #transformTuples, but I forget the details. On Mon, Sep 12, 2016 at 6:36 AM Steve Ebersole wrote: > So

Re: [hibernate-dev] 6.0 - ResultTransformer

So your example actually leverages both methods... Well technically it only really needs the latter method (#transformList); you could have done all that work there - the elements of the passed collection would be the individual tuples. On Mon, Sep 12, 2016 at 6:09 AM Vlad Mihalcea

Re: [hibernate-dev] 6.0 - ResultTransformer

Sure. I've used it recently to group a tree-like structure as follows: public class PostCommentScoreResultTransformer implements ResultTransformer { private Map postCommentScoreMap = new HashMap<>(); private List roots = new ArrayList<>(); @Override

Re: [hibernate-dev] 6.0 - ResultTransformer

The former though is specifically what I see no use for. Do you have a specific use case in mind that cannot be addressed by other mechanisms (Tuple, dynamic-instantiation, etc)? On Mon, Sep 12, 2016, 12:38 AM Vlad Mihalcea wrote: > Hi, > > We definitely need to

Re: [hibernate-dev] 6.0 - ResultTransformer

Hi, We definitely need to address the ResultTranformer. Only the former method is what we should be exposing, the latter being used only in one particular use case, so that should be addressed by a different contract. This way we could provide a ResultTransformer using a lambda, which is not

[hibernate-dev] 6.0 - ResultTransformer

Another legacy concept I'd like to revisit as we move to 6.0 is the Hibernate ResultTransformer. I'd argue that ResultTransformer is no longer needed, especially in it's current form. Specifically, ResultTransformer defines 2 distinct ways to transform the results of a query: 1.