Re: [hibernate-dev] 6.0 - ResultTransformer

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(a)hibernate.org&gt; wrote: > On Tue, Sep 13, 2016 at 2:26 AM Gunnar Morling <gunnar(a)hibernate.org&gt; > 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. >