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( () -> ... ) ... 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