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