[hibernate-dev] 6.0 - ResultTransformer
Gunnar Morling
gunnar at hibernate.org
Tue Sep 13 03:25:59 EDT 2016
> Between dynamic-instantiation, Tuple-handling...
To be sure, WDYM by "tuple-handling"?
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.
Either way the solution should be friendly towards Java 8 Lambda style,
i.e. work with functional interfaces (see [2] for a previous discussion of
this very case of result transformers).
--Gunnar
[1] http://in.relation.to/2016/03/02/converting-projection-results-of-full-
text-queries-into-pojos/
[2] http://lists.jboss.org/pipermail/hibernate-dev/2016-March/014409.html
2016-09-13 9:16 GMT+02:00 Christian Beikov <christian.beikov at gmail.com>:
> I'd say one can either use the "new .." syntax, or a
> ResultTransformer/TupleTransformer but not both at the same time.
> IMO you can do your DTO stuff in the transformer which is probably also
> one of the few usecases for ResultTransformer.
>
> Am 13.09.2016 um 01:33 schrieb Steve Ebersole:
> > If we are going to support #transformTuple (in whatever form) we need to
> > decide on a precedence between that, resultClass, dynamic-instantiation,
> etc
> >
> > Specifically, what is the meaning of:
> >
> > session.createQuery( "select new DTO(...) ...", DTO.class )
> > .setTupleTransformer( () -> ... )
> > ...
> >
> > And what if they dont match necessarily, like:
> >
> > session.createQuery( "select new DTO(...) ...", Tuple.class )
> > .setTupleTransformer( () -> ... )
> >
> >
> >
> > On Mon, Sep 12, 2016 at 9:17 AM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> Gail, IIRC one of these methods causes problems with regards to query
> >> result caching. Do I remember that correctly? And if so, do you
> remember
> >> which one? I'd guess #transformTuples, but I forget the details.
> >>
> >>
> >> On Mon, Sep 12, 2016 at 6:36 AM Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>
> >>> So your example actually leverages both methods... Well technically it
> >>> only really needs the latter method (#transformList); you could have
> done
> >>> all that work there - the elements of the passed collection would be
> the
> >>> individual tuples.
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Sep 12, 2016 at 6:09 AM Vlad Mihalcea <mihalcea.vlad at gmail.com
> >
> >>> wrote:
> >>>
> >>>> Sure. I've used it recently to group a tree-like structure as follows:
> >>>>
> >>>> public class PostCommentScoreResultTransformer
> >>>> implements ResultTransformer {
> >>>>
> >>>> private Map<Long, PostCommentScore> postCommentScoreMap = new
> >>>> HashMap<>();
> >>>>
> >>>> private List<PostCommentScore> roots = new ArrayList<>();
> >>>>
> >>>> @Override
> >>>> public Object transformTuple(Object[] tuple, String[] aliases) {
> >>>> PostCommentScore commentScore = (PostCommentScore) tuple[0];
> >>>> Long parentId = commentScore.getParentId();
> >>>> if (parentId == null) {
> >>>> roots.add(commentScore);
> >>>> } else {
> >>>> PostCommentScore parent = postCommentScoreMap.get(parent
> Id);
> >>>> if (parent != null) {
> >>>> parent.addChild(commentScore);
> >>>> }
> >>>> }
> >>>> postCommentScoreMap.putIfAbsent(commentScore.getId(),
> >>>> commentScore);
> >>>> return commentScore;
> >>>> }
> >>>>
> >>>> @Override
> >>>> public List transformList(List collection) {
> >>>> return roots;
> >>>> }
> >>>> }
> >>>>
> >>>> The results were fetched using a Recursive CTE and I wanted the
> results
> >>>> to be assembled back in a N-level hierarchy, starting from a Root
> node.
> >>>>
> >>>> On Mon, Sep 12, 2016 at 1:58 PM, Steve Ebersole <steve at hibernate.org>
> >>>> wrote:
> >>>>
> >>>>> The former though is specifically what I see no use for. Do you
> have a
> >>>>> specific use case in mind that cannot be addressed by other
> mechanisms
> >>>>> (Tuple, dynamic-instantiation, etc)?
> >>>>>
> >>>>> On Mon, Sep 12, 2016, 12:38 AM Vlad Mihalcea <
> mihalcea.vlad at gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> We definitely need to address the ResultTranformer.
> >>>>>> Only the former method is what we should be exposing, the latter
> being
> >>>>>> used only in one particular use case, so that should be addressed
> by a
> >>>>>> different contract.
> >>>>>>
> >>>>>> This way we could provide a ResultTransformer using a lambda, which
> is
> >>>>>> not possible today.
> >>>>>>
> >>>>>> Vlad
> >>>>>>
> >>>>>> On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole <
> steve at hibernate.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Another legacy concept I'd like to revisit as we move to 6.0 is the
> >>>>>>> Hibernate ResultTransformer. I'd argue that ResultTransformer is
> no
> >>>>>>> longer
> >>>>>>> needed, especially in it's current form.
> >>>>>>>
> >>>>>>> Specifically, ResultTransformer defines 2 distinct ways to
> transform
> >>>>>>> the
> >>>>>>> results of a query:
> >>>>>>>
> >>>>>>> 1. `#transformTuple` - this method operates on each "row" of
> the
> >>>>>>> result,
> >>>>>>
> >>>>>>> allowing the user to transform the Object[] into some other
> >>>>>>> structure.
> >>>>>>> This is specifically the one I see no value in moving forward.
> >>>>>>> Between
> >>>>>>> dynamic-instantiation, Tuple-handling, etc I think users have
> the
> >>>>>>> needed
> >>>>>>> capabilities to transform the query result tuples.
> >>>>>>>
> >>>>>> 2. `#transformList` - this one operates on the query result as a
> >>>>>>> whole
> >>>>>>
> >>>>>>> (unless scroll/iterate are used). This method at least adds
> >>>>>>> something that
> >>>>>>> cannot be done in another way. But I'd still personally
> question
> >>>>>>> its
> >>>>>>> overall usefulness.
> >>>>>>>
> >>>>>>> Does anyone have an argument for continuing to support either of
> >>>>>>> these?
> >>>>>>> Personally, I propose just dropping the ResultTransformer support
> >>>>>>> altogether.
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>>> hibernate-dev mailing list
> >>>>>>> hibernate-dev at lists.jboss.org
> >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>>>
> >>>>>>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
More information about the hibernate-dev
mailing list