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 <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 >>>>> >>>> >>>> >>