> 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 ..." syntax cannot be used, but I don't know about tuple-handling. Either way the solution should be friendly towards Java 8 Lambda style, i.e. work with functional interfaces (see [2] for a previous discussion of this very case of result transformers). --Gunnar [1] http://in.relation.to/2016/03/02/converting-projection-results-of-full- text-queries-into-pojos/ [2] http://lists.jboss.org/pipermail/hibernate-dev/2016-March/014409.html 2016-09-13 9:16 GMT+02:00 Christian Beikov <christian.bei...@gmail.com>: > 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 <st...@hibernate.org> > 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 <st...@hibernate.org> > >> 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.v...@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 <st...@hibernate.org> > >>>> 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.v...@gmail.com> > >>>>> 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 < > st...@hibernate.org> > >>>>>> 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@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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
