[hibernate-dev] 6.0 - ResultTransformer

[Emmanuel Bernard]

My preference would be to keep some form of resultTransformer around,
especially the first method that is redundant.

And it's mainly because it is very easy to write one and plug. The HQL
based instantiation is fine when you use it but as Gunnar mentioned,
this is not always the case. What is the Tuple handling method BTW?

For ordering, I always thought if result transformers as happening after
the result of a query. Since the query transform things into DTO objects
in your example, the result transformer would receive DTO.

BTW what does happen in this case?
session.createQuery( "select new DTO(...) ...", Tuple.class ).list();

Some exception or is Tuple treated specifically?

Emmanuel

On Mon 2016-09-12 23:33, Steve Ebersole wrote:
>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
>>>>>>>
>>>>>>
>>>>>>
>>>>
>_______________________________________________
>hibernate-dev mailing list
>hibernate-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/hibernate-dev