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 <st...@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 <st...@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.v...@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 <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
