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 <st...@hibernate.org> wrote:
> On Tue, Sep 13, 2016 at 2:26 AM Gunnar Morling <gun...@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.
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
