[hibernate-dev] 6.0 - ResultTransformer

[Steve Ebersole]

So again, this all boils down to the interplay with
(Result|Tuple|ResultList)Transformer, dynamic instantiations, and
result-types.

So let's look at some specific cases...

First some cases I think are perfectly valid:

session.createQuery( "select new map(...) ...", Map.class ) - returns a
List<Map<String,?>>
session.createQuery( "select new list(...) ...", List.class ) - returns a
List<List> (rather than List<Object[]>)
session.createQuery( "select new DTO(...), DTO.class ) - returns a List<DTO>

Ok, so I cheated there by not including transformers :)  So let's look at
adding transformers into this mix[1].

session.createQuery( "select new map(...) ...", Map.class )
        .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )

this one is illegal.  It defines the Query resultType as Map, but the
applied TupleTranformer is transforming those to SomeNonMap -> CCE.  This
should be either:

session.createQuery( "select new map(...) ...", SomeNonMap.class )
        .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )

or (non-typed):

session.createQuery( "select new map(...) ..." )
        .setTupleTransformer( new TupleTranformer<SomeNonMap>() {...} )

In both of those cases, the TupleTranformer is handed a Object[] where the
only element is the Map.

I guess too that defines the blueprint for what is and what is not
supported and how the various pieces apply.


But I am still not sure about the semantic wrt TupleTransformer and/or
dynamic-instantiation in combination with Tuple.  I kind of think those
should just be illegal combos:

session.createQuery( "select ...", Tuple.class )
        .setTupleTransformer( () -> ... )

Unless the TupleTransformer is building a Tuple, I that is a bad combo for
sure.

I thik dynamic-instantiation and TupleTransformer is ok:

session.createQuery( "select new DTO(...) ..." )
        .setTupleTransformer( () -> ... )

Here the TupleTransformer would get Object[] with the long element being
the DTO; the "query result" is whatever the TupleTransformer returns.

Any other specific combos we should clarify?



[1]  I am using the new TupleTransformer and ResultListTransformer
breakdowns I have defined on 6.0 :
https://gist.github.com/sebersole/bc721caa20a5e4a97cbde44567b0b2ea



On Tue, Sep 13, 2016 at 8:52 AM Steve Ebersole <steve at hibernate.org> wrote:

> On Tue, Sep 13, 2016 at 2:26 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> > Between dynamic-instantiation, Tuple-handling...
>>
>> To be sure, WDYM by "tuple-handling"?
>>
>
> javax.persistence.Tuple
>
> So I gave just one example earlier of how all of these things do not
> necessarily fit together in inherently obvious ways.  Some combinations I
> think are ok; others are not.  In sitting here and trying to describe this
> to a user from a documentation perspective, it is not a simple explanation.
>
> I'll follow up with a separate reply that covers those combos for
> discussion.
>
>
> One use case for result transformers are full-text searches executed
>> through Hibernate Search's Session extension FullTextSession (see [1]).
>>
>> For full-text searches we don't use HQL/JPQL, so the "new ..." syntax
>> cannot be used, but I don't know about tuple-handling.
>>
>
> Well for sure you do not allow the user to use HQL/JPQL.  But I'd have to
> assume that under the covers you handle resolving that FullTextQuery
> yourself from the indexes - which means this is not even a ORM Query at all
> and what we do with ResultTransformer in ORM in regards to Query is
> completely irrelevant for you.  In other words I would have to think that
> Search itself is applying that ResultTransformer in your example, not ORM.
> Very different.
>