[hibernate-dev] 6.0 - ResultTransformer

[Steve Ebersole]

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 at hibernate.org> 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 at hibernate.org>
> 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 at gmail.com>
>> 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 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
>>>>>>
>>>>>
>>>>>
>>>