[hibernate-dev] 6.0 - ResultTransformer

[Steve Ebersole]

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
>>>>
>>>
>>>
>