[hibernate-dev] 6.0 - ResultTransformer

Steve Ebersole steve at hibernate.org
Tue Sep 13 09:59:47 EDT 2016

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

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

More information about the hibernate-dev mailing list