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