BTW... https://hibernate.atlassian.net/browse/HHH-11104
On Tue, Sep 13, 2016 at 7:05 PM Steve Ebersole <st...@hibernate.org> wrote: > Hmmm there is an interesting aspect to Tuple + TupleTransformer.. both > expect to get the root selection aliases and would naturally expect those > to match in length to the values to transform. Basically only one can > "consume" the aliases. > > I think that because Tuple is a "higher precedence" (it defines the result > type) it ought to win that battle. But then that is inconsistent for > TupleTransformer. IMO either we let Tuple consume the aliases or we > disallow this combo. > > On Tue, Sep 13, 2016 at 6:00 PM Steve Ebersole <st...@hibernate.org> > wrote: > >> 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