[hibernate-dev] 6.0 - ResultTransformer
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