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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev