[hibernate-dev] 6.0 - ResultTransformer

[Christian Beikov]

I'd say one can either use the "new .." syntax, or a 
ResultTransformer/TupleTransformer but not both at the same time.
IMO you can do your DTO stuff in the transformer which is probably also 
one of the few usecases for ResultTransformer.

Am 13.09.2016 um 01:33 schrieb 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
>>>>>>>
>>>>>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev