[hibernate-dev] 6.0 - ResultTransformer

[Steve Ebersole]

On Tue, Sep 13, 2016 at 5:23 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> My preference would be to keep some form of resultTransformer around,
> especially the first method that is redundant.
>
> And it's mainly because it is very easy to write one and plug. The HQL
> based instantiation is fine when you use it but as Gunnar mentioned,
> this is not always the case. What is the Tuple handling method BTW?
>

Well if you refer to the Search case Gunnar mentioned, I do not think that
is valid per this discussion (how ResultTransformer plugs into the ORM
Query contract) as I mentioned in my reply to him.


For ordering, I always thought if result transformers as happening after
> the result of a query. Since the query transform things into DTO objects
> in your example, the result transformer would receive DTO.
>

All of these things get applied "after the query".  In fact
dynamic-instantiation and Tuple-handling are today (5.x and prior) handled
by plugging in an implicit ResultTransformer!  You can see part of the
problem :)  Personally I think routing those through ResultTransformer is a
bad idea, and that will change in 6.0.


BTW what does happen in this case?
> session.createQuery( "select new DTO(...) ...", Tuple.class ).list();
>
> Some exception or is Tuple treated specifically?
>

TBH I am not sure.  TIAS. But like I said  dynamic-instantiation and
Tuple-handling are handled internally as ResultTransformers, so my guess is
that the last one wins.