[hibernate-dev] ScrollableResults and 6.0

Gunnar Morling gunnar at hibernate.org
Tue Jan 3 06:39:34 EST 2017


2017-01-03 11:57 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> It sounds great but I'm not sure it's possible?
>

WDYM specifically?

For example how would this handle projections? I guess it's a similar
> doubt as the one Gunnar shared, but while he suggests a semi-typesafe
> solution, I'm not sure how cool it is to give the feeling that types
> are being checked when they might actually blow at runtime, if the
> query string doesn't match expectations.
> Could an Annotation Processor verify the declared return types really
> match the HQL select?
>

I understand your point, but isn't it the same for createQuery( "from Foo",
Bar.class )? This also will only be detected at runtime. I.e. I don't see
how it's worse for the tuple approach?

Btw. we'd one Tuple type per number of returns, i.e. Tuple2, Tuple3 etc.,
each with the right number of type arguments. As said I'm not fully
convinced myself, but some may find it nicer to use than casting the
elements of an array.

Assuming the answer is no, I'd prefer the return types to explicitly
> highlight the need for casting by using "Object[]": I suspect errors
> leading to a type mismatch would produce more understandable errors.
>
>
> On 2 January 2017 at 14:09, Steve Ebersole <steve at hibernate.org> wrote:
> > I knew of the request.  Its just that on the EE group I am sure the
> > decision will be consistency.
> >
> > On Mon, Jan 2, 2017 at 7:11 AM Yoann Rodiere <yoann at hibernate.org>
> wrote:
> >
> >> > 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.
> >>
> >> Sure. I just wanted to point out that scrolling isn't part of JPA yet,
> but
> >> there are plans to add it, so we might as well try to know what form it
> >> will take in JPA 2.2 in order to make the change future-proof.
> >>
> >> To be perfectly clear: it was just a heads-up because I came accross
> this
> >> JPA ticket a few weeks ago, I don't have any specific concern in mind.
> If
> >> you think it's not relevant, sorry for the noise.
> >>
> >>
> >> Yoann Rodière <yoann at hibernate.org>
> >> Hibernate NoORM Team
> >>
> >> On 2 January 2017 at 12:42, Steve Ebersole <steve at hibernate.org> wrote:
> >>
> >> 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 <yoann at 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 <yoann at hibernate.org>
> >> Hibernate NoORM Team
> >>
> >> On 27 December 2016 at 22:02, Steve Ebersole <steve at 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 <steve at 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 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