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
>