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(a)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(a)hibernate.org>
Hibernate NoORM Team
On 2 January 2017 at 12:42, Steve Ebersole <steve(a)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(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:
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(a)hibernate.org>
Hibernate NoORM Team
On 27 December 2016 at 22:02, Steve Ebersole <steve(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev