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 =
"select p, a, c from ...",
Person.class, Address.class, CustomerType.class
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
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 <steve(a)hibernate.org>:
org.hibernate.query.Query extends javax.persistence.TypedQuery since
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 <yoann(a)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:
. 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
> Not sure there would be many reactions, judging by the low activity on
> ticket, but who knows...
> Yoann Rodière <yoann(a)hibernate.org>
> Hibernate NoORM Team
> On 27 December 2016 at 22:02, Steve Ebersole <steve(a)hibernate.org>
> 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 <steve(a)hibernate.org>
> > For 6.0 I'd like to also make ScrollableResults parameterized wrt the
> > 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
> > of the existing methods? Or add new methods?
> hibernate-dev mailing list
hibernate-dev mailing list