[hibernate-dev] 6.0 - ResultTransformer

[Vlad Mihalcea]

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 at 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 at 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 at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>