Re: [hibernate-dev] 6.0 - ResultTransformer
On Tue, Sep 13, 2016 at 5:23 AM Emmanuel Bernard <emmanuel(a)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.