What's the overall strategy for aligning the classic Query API with JPA for
Hibernate ORM 6? Are you e.g. going to remove uniqueResult() as it's
superseded by JPA's getSingleResult()?
If so, I also vote for changing the existing method on ScrollableResults.
Thinking about this, should there be support for type-safe retrieval of
query results with multiple returns? E.g. something like this:
ScrollableResults<Tuple3<Person, Address, CustomerType>> sr =
session.createQuery(
"select p, a, c from ...",
Person.class, Address.class, CustomerType.class
).scroll();
Person p = sr.get().get1();
Address a = sr.get().get2();
CustomerType c = sr.get().get3();
It'd require a few TupleN classes and an overload of createQuery() for each
N. For a large number of returns one would still have to fall back to
object arrays.
Not sure whether it pulls its weight, but I thought I'd throw out the idea.
2017-01-02 12:42 GMT+01:00 Steve Ebersole <st...@hibernate.org>:
> org.hibernate.query.Query extends javax.persistence.TypedQuery since 5.2,
> so it already has been parameterized.
>
> Regarding JPA adopting scrolling as a feature, what I suggest simply
> follows what Hibernate ans JPA already do for other Query returns. Today
> it is completely inconsistent between Query#scroll and Query#list e.g.. I
> am just suggesting making that consistent.
>
> On Mon, Jan 2, 2017 at 2:36 AM Yoann Rodiere <yo...@hibernate.org> wrote:
>
> > For what it's worth, changing the signature indeed seems appropriate to
> > me: the fewer object arrays, the better.
> > Your proposal would require making Query parameterized too, though. I'm
> > not really up-to-date with the current state of 6.0, but I guess it's
> > already done or being done.
> >
> > Anyway, the only think I wanted to say was: if we break the API, maybe we
> > should try to make sure we won't have to break it again soon. There has
> > been some discussions about adding scrolling to the JPA spec:
> > https://java.net/jira/browse/JPA_SPEC-89 . Maybe it would be worth it to
> > ask for advice on this ticket, so as to limit the risk of having to break
> > this API again, because the spec would introduce an incompatible
> signature?
> > Not sure there would be many reactions, judging by the low activity on
> the
> > ticket, but who knows...
> >
> > Yoann Rodière <yo...@hibernate.org>
> > Hibernate NoORM Team
> >
> > On 27 December 2016 at 22:02, Steve Ebersole <st...@hibernate.org>
> wrote:
> >
> > FWIW my inclination is to just change the existing signatures. 6.0 is a
> > major release with major changes already wrt querying.
> >
> >
> >
> > On Tue, Dec 27, 2016 at 3:01 PM Steve Ebersole <st...@hibernate.org>
> > wrote:
> >
> > > For 6.0 I'd like to also make ScrollableResults parameterized wrt the
> > "row
> > > type". E.g.
> > >
> > > ScrollableResults<Person> sr = session.createQuery( ..., Person.class
> > > ).scroll();
> > >
> > > However that changes the signature of its methods returning a "row"
> > > (currently always defined as Object[]).
> > >
> > > How would everyone prefer we handle this? Do I just change the
> > signatures
> > > of the existing methods? Or add new methods?
> > >
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
