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
