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 possible today. Vlad On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > 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. `#transformTuple` - this method operates on each "row" of the > result, > allowing the user to transform the Object[] into some other structure. > This is specifically the one I see no value in moving forward. Between > dynamic-instantiation, Tuple-handling, etc I think users have the > needed > capabilities to transform the query result tuples. > 2. `#transformList` - this one operates on the query result as a whole > (unless scroll/iterate are used). This method at least adds something > that > cannot be done in another way. But I'd still personally question its > overall usefulness. > > Does anyone have an argument for continuing to support either of these? > Personally, I propose just dropping the ResultTransformer support > altogether. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

Sure. I've used it recently to group a tree-like structure as follows: public class PostCommentScoreResultTransformer implements ResultTransformer { private Map<Long, PostCommentScore> postCommentScoreMap = new HashMap<>(); private List<PostCommentScore> roots = new ArrayList<>(); @Override public Object transformTuple(Object[] tuple, String[] aliases) { PostCommentScore commentScore = (PostCommentScore) tuple[0]; Long parentId = commentScore.getParentId(); if (parentId == null) { roots.add(commentScore); } else { PostCommentScore parent = postCommentScoreMap.get(parentId); if (parent != null) { parent.addChild(commentScore); } } postCommentScoreMap.putIfAbsent(commentScore.getId(), commentScore); return commentScore; } @Override public List transformList(List collection) { return roots; } } The results were fetched using a Recursive CTE and I wanted the results to be assembled back in a N-level hierarchy, starting from a Root node. On Mon, Sep 12, 2016 at 1:58 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > 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 <mihalcea.vlad(a)gmail.com&gt; > wrote: > >> 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 possible today. >> >> Vlad >> >> On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> 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. `#transformTuple` - this method operates on each "row" of the >>> result, >> >> >>> allowing the user to transform the Object[] into some other >>> structure. >>> This is specifically the one I see no value in moving forward. >>> Between >>> dynamic-instantiation, Tuple-handling, etc I think users have the >>> needed >>> capabilities to transform the query result tuples. >>> >> 2. `#transformList` - this one operates on the query result as a whole >> >> >>> (unless scroll/iterate are used). This method at least adds >>> something that >>> cannot be done in another way. But I'd still personally question >>> its >>> overall usefulness. >>> >>> Does anyone have an argument for continuing to support either of these? >>> Personally, I propose just dropping the ResultTransformer support >>> altogether. >>> >> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >>

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 <steve(a)hibernate.org&gt; wrote: > 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 <mihalcea.vlad(a)gmail.com&gt; > wrote: > >> Sure. I've used it recently to group a tree-like structure as follows: >> >> public class PostCommentScoreResultTransformer >> implements ResultTransformer { >> >> private Map<Long, PostCommentScore> postCommentScoreMap = new >> HashMap<>(); >> >> private List<PostCommentScore> roots = new ArrayList<>(); >> >> @Override >> public Object transformTuple(Object[] tuple, String[] aliases) { >> PostCommentScore commentScore = (PostCommentScore) tuple[0]; >> Long parentId = commentScore.getParentId(); >> if (parentId == null) { >> roots.add(commentScore); >> } else { >> PostCommentScore parent = postCommentScoreMap.get(parentId); >> if (parent != null) { >> parent.addChild(commentScore); >> } >> } >> postCommentScoreMap.putIfAbsent(commentScore.getId(), >> commentScore); >> return commentScore; >> } >> >> @Override >> public List transformList(List collection) { >> return roots; >> } >> } >> >> The results were fetched using a Recursive CTE and I wanted the results >> to be assembled back in a N-level hierarchy, starting from a Root node. >> >> On Mon, Sep 12, 2016 at 1:58 PM, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> 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 <mihalcea.vlad(a)gmail.com&gt; >>> wrote: >>> >>>> 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 possible today. >>>> >>>> Vlad >>>> >>>> On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole <steve(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> 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. `#transformTuple` - this method operates on each "row" of the >>>>> result, >>>> >>>> >>>>> allowing the user to transform the Object[] into some other >>>>> structure. >>>>> This is specifically the one I see no value in moving forward. >>>>> Between >>>>> dynamic-instantiation, Tuple-handling, etc I think users have the >>>>> needed >>>>> capabilities to transform the query result tuples. >>>>> >>>> 2. `#transformList` - this one operates on the query result as a >>>>> whole >>>> >>>> >>>>> (unless scroll/iterate are used). This method at least adds >>>>> something that >>>>> cannot be done in another way. But I'd still personally question >>>>> its >>>>> overall usefulness. >>>>> >>>>> Does anyone have an argument for continuing to support either of >>>>> these? >>>>> Personally, I propose just dropping the ResultTransformer support >>>>> altogether. >>>>> >>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>> >>>> >>

Between dynamic-instantiation, Tuple-handling...

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 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( () -> ... ) > ... > > And what if they dont match necessarily, like: > > session.createQuery( "select new DTO(...) ...", Tuple.class ) > .setTupleTransformer( () -> ... ) > > > > On Mon, Sep 12, 2016 at 9:17 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > >> 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 <steve(a)hibernate.org&gt; >> wrote: >> >>> 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 <mihalcea.vlad(a)gmail.com > >>> wrote: >>> >>>> Sure. I've used it recently to group a tree-like structure as follows: >>>> >>>> public class PostCommentScoreResultTransformer >>>> implements ResultTransformer { >>>> >>>> private Map<Long, PostCommentScore> postCommentScoreMap = new >>>> HashMap<>(); >>>> >>>> private List<PostCommentScore> roots = new ArrayList<>(); >>>> >>>> @Override >>>> public Object transformTuple(Object[] tuple, String[] aliases) { >>>> PostCommentScore commentScore = (PostCommentScore) tuple[0]; >>>> Long parentId = commentScore.getParentId(); >>>> if (parentId == null) { >>>> roots.add(commentScore); >>>> } else { >>>> PostCommentScore parent = postCommentScoreMap.get(parent Id); >>>> if (parent != null) { >>>> parent.addChild(commentScore); >>>> } >>>> } >>>> postCommentScoreMap.putIfAbsent(commentScore.getId(), >>>> commentScore); >>>> return commentScore; >>>> } >>>> >>>> @Override >>>> public List transformList(List collection) { >>>> return roots; >>>> } >>>> } >>>> >>>> The results were fetched using a Recursive CTE and I wanted the results >>>> to be assembled back in a N-level hierarchy, starting from a Root node. >>>> >>>> On Mon, Sep 12, 2016 at 1:58 PM, Steve Ebersole <steve(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> 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 < mihalcea.vlad(a)gmail.com&gt; >>>>> wrote: >>>>> >>>>>> 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 possible today. >>>>>> >>>>>> Vlad >>>>>> >>>>>> On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole < steve(a)hibernate.org&gt; >>>>>> wrote: >>>>>> >>>>>>> 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. `#transformTuple` - this method operates on each "row" of the >>>>>>> result, >>>>>> >>>>>>> allowing the user to transform the Object[] into some other >>>>>>> structure. >>>>>>> This is specifically the one I see no value in moving forward. >>>>>>> Between >>>>>>> dynamic-instantiation, Tuple-handling, etc I think users have the >>>>>>> needed >>>>>>> capabilities to transform the query result tuples. >>>>>>> >>>>>> 2. `#transformList` - this one operates on the query result as a >>>>>>> whole >>>>>> >>>>>>> (unless scroll/iterate are used). This method at least adds >>>>>>> something that >>>>>>> cannot be done in another way. But I'd still personally question >>>>>>> its >>>>>>> overall usefulness. >>>>>>> >>>>>>> Does anyone have an argument for continuing to support either of >>>>>>> these? >>>>>>> Personally, I propose just dropping the ResultTransformer support >>>>>>> altogether. >>>>>>> >>>>>> _______________________________________________ >>>>>>> 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 _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Tue, Sep 13, 2016 at 2:26 AM Gunnar Morling <gunnar(a)hibernate.org&gt; 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 inherently obvious ways. Some combinations I think are ok; others are not. In sitting here and trying to describe this to a user from a documentation perspective, it is not a simple explanation. I'll follow up with a separate reply that covers those combos for discussion. 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 ..." syntax > cannot be used, but I don't know about tuple-handling. > Well for sure you do not allow the user to use HQL/JPQL. But I'd have to assume that under the covers you handle resolving that FullTextQuery yourself from the indexes - which means this is not even a ORM Query at all and what we do with ResultTransformer in ORM in regards to Query is completely irrelevant for you. In other words I would have to think that Search itself is applying that ResultTransformer in your example, not ORM. Very different.

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, specifically I defined 2 levels: 1. an implicit RowTransformer. This is resolved based on the following chart: 1. If there is a resultType and it is Object[].class we do a "pass thru" 2. If there is a resultType and it is Tuple.class we do use a RowTransformer adapter that builds a Tuple 3. If there is just one selection we transform the Object[] by returning just row[0] 2. a RowTransformer adapter for TupleTransformer, if specified And just a word on dynamic-instantiation here.. it is actually done prior to any of this. In fact, in 6.0 a dynamic-instantiation is no different that other selectable expressions. On Tue, Sep 13, 2016 at 9:19 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > 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 > List<Map<String,?>> > session.createQuery( "select new list(...) ...", List.class ) - returns a > List<List> (rather than List<Object[]>) > session.createQuery( "select new DTO(...), DTO.class ) - returns a > List<DTO> > > Ok, so I cheated there by not including transformers :) So let's look at > adding transformers into this mix[1]. > > session.createQuery( "select new map(...) ...", Map.class ) > .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} ) > > this one is illegal. It defines the Query resultType as Map, but the > applied TupleTranformer is transforming those to SomeNonMap -> CCE. > This should be either: > > session.createQuery( "select new map(...) ...", SomeNonMap.class ) > .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} ) > > or (non-typed): > > session.createQuery( "select new map(...) ..." ) > .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} ) > > In both of those cases, the TupleTranformer is handed a Object[] where > the only element is the Map. > > I guess too that defines the blueprint for what is and what is not > supported and how the various pieces apply. > > > But I am still not sure about the semantic wrt TupleTransformer and/or > dynamic-instantiation in combination with Tuple. I kind of think those > should just be illegal combos: > > session.createQuery( "select ...", Tuple.class ) > .setTupleTransformer( () -> ... ) > > Unless the TupleTransformer is building a Tuple, I that is a bad combo > for sure. > > I thik dynamic-instantiation and TupleTransformer is ok: > > session.createQuery( "select new DTO(...) ..." ) > .setTupleTransformer( () -> ... ) > > Here the TupleTransformer would get Object[] with the long element being > the DTO; the "query result" is whatever the TupleTransformer returns. > > Any other specific combos we should clarify? > > > > [1] I am using the new TupleTransformer and ResultListTransformer > breakdowns I have defined on 6.0 : > https://gist.github.com/sebersole/bc721caa20a5e4a97cbde44567b0b2ea > > > > On Tue, Sep 13, 2016 at 8:52 AM Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> On Tue, Sep 13, 2016 at 2:26 AM Gunnar Morling <gunnar(a)hibernate.org&gt; >> 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 inherently obvious ways. Some combinations >> I think are ok; others are not. In sitting here and trying to describe >> this to a user from a documentation perspective, it is not a simple >> explanation. >> >> I'll follow up with a separate reply that covers those combos for >> discussion. >> >> >> 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 ..." syntax >>> cannot be used, but I don't know about tuple-handling. >>> >> >> Well for sure you do not allow the user to use HQL/JPQL. But I'd have >> to assume that under the covers you handle resolving that FullTextQuery >> yourself from the indexes - which means this is not even a ORM Query at all >> and what we do with ResultTransformer in ORM in regards to Query is >> completely irrelevant for you. In other words I would have to think that >> Search itself is applying that ResultTransformer in your example, not ORM. >> Very different. >> >

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 defines the result type) it ought to win that battle. But then that is inconsistent for TupleTransformer. IMO either we let Tuple consume the aliases or we disallow this combo. On Tue, Sep 13, 2016 at 6:00 PM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > 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, specifically I defined 2 > levels: > > 1. an implicit RowTransformer. This is resolved based on the > following chart: > 1. If there is a resultType and it is Object[].class we do a "pass > thru" > 2. If there is a resultType and it is Tuple.class we do use a > RowTransformer adapter that builds a Tuple > 3. If there is just one selection we transform the Object[] by > returning just row[0] > 2. a RowTransformer adapter for TupleTransformer, if specified > > And just a word on dynamic-instantiation here.. it is actually done prior > to any of this. In fact, in 6.0 a dynamic-instantiation is no different > that other selectable expressions. > > > > On Tue, Sep 13, 2016 at 9:19 AM Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> 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 >> List<Map<String,?>> >> session.createQuery( "select new list(...) ...", List.class ) - returns a >> List<List> (rather than List<Object[]>) >> session.createQuery( "select new DTO(...), DTO.class ) - returns a >> List<DTO> >> >> Ok, so I cheated there by not including transformers :) So let's look at >> adding transformers into this mix[1]. >> >> session.createQuery( "select new map(...) ...", Map.class ) >> .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} ) >> >> this one is illegal. It defines the Query resultType as Map, but the >> applied TupleTranformer is transforming those to SomeNonMap -> CCE. >> This should be either: >> >> session.createQuery( "select new map(...) ...", SomeNonMap.class ) >> .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} ) >> >> or (non-typed): >> >> session.createQuery( "select new map(...) ..." ) >> .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} ) >> >> In both of those cases, the TupleTranformer is handed a Object[] where >> the only element is the Map. >> >> I guess too that defines the blueprint for what is and what is not >> supported and how the various pieces apply. >> >> >> But I am still not sure about the semantic wrt TupleTransformer and/or >> dynamic-instantiation in combination with Tuple. I kind of think those >> should just be illegal combos: >> >> session.createQuery( "select ...", Tuple.class ) >> .setTupleTransformer( () -> ... ) >> >> Unless the TupleTransformer is building a Tuple, I that is a bad combo >> for sure. >> >> I thik dynamic-instantiation and TupleTransformer is ok: >> >> session.createQuery( "select new DTO(...) ..." ) >> .setTupleTransformer( () -> ... ) >> >> Here the TupleTransformer would get Object[] with the long element being >> the DTO; the "query result" is whatever the TupleTransformer returns. >> >> Any other specific combos we should clarify? >> >> >> >> [1] I am using the new TupleTransformer and ResultListTransformer >> breakdowns I have defined on 6.0 : >> https://gist.github.com/sebersole/bc721caa20a5e4a97cbde44567b0b2ea >> >> >> >> On Tue, Sep 13, 2016 at 8:52 AM Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> On Tue, Sep 13, 2016 at 2:26 AM Gunnar Morling <gunnar(a)hibernate.org&gt; >>> 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 inherently obvious ways. Some combinations >>> I think are ok; others are not. In sitting here and trying to describe >>> this to a user from a documentation perspective, it is not a simple >>> explanation. >>> >>> I'll follow up with a separate reply that covers those combos for >>> discussion. >>> >>> >>> 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 ..." syntax >>>> cannot be used, but I don't know about tuple-handling. >>>> >>> >>> Well for sure you do not allow the user to use HQL/JPQL. But I'd have >>> to assume that under the covers you handle resolving that FullTextQuery >>> yourself from the indexes - which means this is not even a ORM Query at all >>> and what we do with ResultTransformer in ORM in regards to Query is >>> completely irrelevant for you. In other words I would have to think that >>> Search itself is applying that ResultTransformer in your example, not ORM. >>> Very different. >>> >> _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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( () -> ... ) ... And what if they dont match necessarily, like: session.createQuery( "select new DTO(...) ...", Tuple.class ) .setTupleTransformer( () -> ... ) On Mon, Sep 12, 2016 at 9:17 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > 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 <steve(a)hibernate.org&gt; > wrote: > >> 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 <mihalcea.vlad(a)gmail.com&gt; >> wrote: >> >>> Sure. I've used it recently to group a tree-like structure as follows: >>> >>> public class PostCommentScoreResultTransformer >>> implements ResultTransformer { >>> >>> private Map<Long, PostCommentScore> postCommentScoreMap = new >>> HashMap<>(); >>> >>> private List<PostCommentScore> roots = new ArrayList<>(); >>> >>> @Override >>> public Object transformTuple(Object[] tuple, String[] aliases) { >>> PostCommentScore commentScore = (PostCommentScore) tuple[0]; >>> Long parentId = commentScore.getParentId(); >>> if (parentId == null) { >>> roots.add(commentScore); >>> } else { >>> PostCommentScore parent = postCommentScoreMap.get(parentId); >>> if (parent != null) { >>> parent.addChild(commentScore); >>> } >>> } >>> postCommentScoreMap.putIfAbsent(commentScore.getId(), >>> commentScore); >>> return commentScore; >>> } >>> >>> @Override >>> public List transformList(List collection) { >>> return roots; >>> } >>> } >>> >>> The results were fetched using a Recursive CTE and I wanted the results >>> to be assembled back in a N-level hierarchy, starting from a Root node. >>> >>> On Mon, Sep 12, 2016 at 1:58 PM, Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> 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 <mihalcea.vlad(a)gmail.com&gt; >>>> wrote: >>>> >>>>> 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 possible today. >>>>> >>>>> Vlad >>>>> >>>>> On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole <steve(a)hibernate.org&gt; >>>>> wrote: >>>>> >>>>>> 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. `#transformTuple` - this method operates on each "row" of the >>>>>> result, >>>>> >>>>> >>>>>> allowing the user to transform the Object[] into some other >>>>>> structure. >>>>>> This is specifically the one I see no value in moving forward. >>>>>> Between >>>>>> dynamic-instantiation, Tuple-handling, etc I think users have the >>>>>> needed >>>>>> capabilities to transform the query result tuples. >>>>>> >>>>> 2. `#transformList` - this one operates on the query result as a >>>>>> whole >>>>> >>>>> >>>>>> (unless scroll/iterate are used). This method at least adds >>>>>> something that >>>>>> cannot be done in another way. But I'd still personally question >>>>>> its >>>>>> overall usefulness. >>>>>> >>>>>> Does anyone have an argument for continuing to support either of >>>>>> these? >>>>>> Personally, I propose just dropping the ResultTransformer support >>>>>> altogether. >>>>>> >>>>> _______________________________________________ >>>>>> 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