So here is the path I am following initially.. It is straightforward to explain to a user which I like.
In terms of processing each "row" in a result there is the RowTransformer contract I mentioned earlier, or maybe I mentioned on HipChat. I added the capability for RowTransformer to be nested, specifically I defined 2 levels: 1. an implicit RowTransformer. This is resolved based on the following chart: 1. If there is a resultType and it is Object[].class we do a "pass thru" 2. If there is a resultType and it is Tuple.class we do use a RowTransformer adapter that builds a Tuple 3. If there is just one selection we transform the Object[] by returning just row[0] 2. a RowTransformer adapter for TupleTransformer, if specified And just a word on dynamic-instantiation here.. it is actually done prior to any of this. In fact, in 6.0 a dynamic-instantiation is no different that other selectable expressions. On Tue, Sep 13, 2016 at 9:19 AM Steve Ebersole <st...@hibernate.org> wrote: > 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