Re: [hibernate-dev] ScrollableResults and 6.0

2017-01-09 Thread Vlad Mihalcea
I'm also for changing the signature, therefore simplifying the implementation. We've had some issues due to the fact that it expects Object[] and Chris and I had to do some hacks to fix them. Vlad On Tue, Jan 3, 2017 at 10:39 PM, Chris Cranford wrote: > Steve - > > I'm

Re: [hibernate-dev] ScrollableResults and 6.0

2017-01-03 Thread Chris Cranford
Steve - I'm inclined to agree that changing signatures makes the most sense at this point. Chris On 12/27/2016 04:02 PM, Steve Ebersole 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

Re: [hibernate-dev] ScrollableResults and 6.0

2017-01-03 Thread Steve Ebersole
Inline... On Tue, Jan 3, 2017 at 5:39 AM Gunnar Morling wrote: > 2017-01-03 11:57 GMT+01:00 Sanne Grinovero : > > 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

Re: [hibernate-dev] ScrollableResults and 6.0

2017-01-03 Thread Steve Ebersole
Inline... On Tue, Jan 3, 2017 at 4:58 AM Sanne Grinovero wrote: > It sounds great but I'm not sure it's possible? > No idea what this means. Its more than possible. In fact its already largely done. What do you mean? For example how would this handle projections?

Re: [hibernate-dev] ScrollableResults and 6.0

2017-01-03 Thread Sanne Grinovero
On 3 January 2017 at 11:39, Gunnar Morling wrote: > 2017-01-03 11:57 GMT+01:00 Sanne Grinovero : >> >> 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 >>

Re: [hibernate-dev] ScrollableResults and 6.0

2017-01-03 Thread Gunnar Morling
2017-01-03 11:57 GMT+01:00 Sanne Grinovero : > 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

Re: [hibernate-dev] ScrollableResults and 6.0

2017-01-03 Thread Sanne Grinovero
It sounds great but I'm not sure it's possible? 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

Re: [hibernate-dev] ScrollableResults and 6.0

2017-01-02 Thread Steve Ebersole
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 wrote: > > Regarding JPA adopting scrolling as a feature, what I suggest simply > follows what Hibernate ans JPA already do for

Re: [hibernate-dev] ScrollableResults and 6.0

2017-01-02 Thread Yoann Rodiere
> 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

Re: [hibernate-dev] ScrollableResults and 6.0

2017-01-02 Thread Gunnar Morling
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

Re: [hibernate-dev] ScrollableResults and 6.0

2017-01-02 Thread Steve Ebersole
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