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
