Re: [hibernate-dev] ScrollableResults and 6.0
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 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 27, 2016 at 3:01 PM Steve Ebersole > wrote: > > > >> For 6.0 I'd like to also make ScrollableResults parameterized wrt the > "row > >> type". E.g. > >> > >> ScrollableResults 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
Re: [hibernate-dev] ScrollableResults and 6.0
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 27, 2016 at 3:01 PM Steve Ebersole wrote: > >> For 6.0 I'd like to also make ScrollableResults parameterized wrt the "row >> type". E.g. >> >> ScrollableResults 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
Re: [hibernate-dev] ScrollableResults and 6.0
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 not fully
> convinced myself, but some may find it nicer to use than casting the
> elements of an array.
>
That is not how Tuple works in list()/uniqueResult() even.
Look, ultimately all I am proposing here is to make Query#scroll work the
same as, e.g., Query#list in terms of its return signature.
For Query#list you do not get back multiple Tuple objects (per
"row"). Why would you here?
Perhaps y'all are getting hung up on the name Tuple. Tuple represents the
entire row, each "column" in that row. E.g.
List results = session.createQuery( "select e.prop1 as p1, e.prop2
as p2 from Entity e", Tuple.class ).list();
for ( Tuple tuple : results ) {
// access "prop1":
tuple.get(0)
tuple.get("p1")
...
// access "prop2":
tuple.get(1)
tuple.get("p2")
...
}
Tuple is really just a "nicer" (ymmv) way to deal with Object[]...
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] ScrollableResults and 6.0
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? Exactly the same way you'd handle them for list(), uniqueResult(), etc. E.g. using list(): List results = session.createQuery( "select p.name.first, p.name.last from Person p" ).list(); vs. ScrollableResults results = session.createQuery( "select p.name.first, p.name.last from Person p" ).scroll(); or using Tuples if you prefer: List results = session.createQuery( "select p.name.first, p.name.last from Person p", Tuple.class ).list(); vs. ScrollableResults results = session.createQuery( "select p.name.first, p.name.last from Person p", Tuple.class ).scroll(); > 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 really have no idea what this is all about... ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] ScrollableResults and 6.0
> If only someone here was a expert of annotation processors maybe he > could tell me if I'm dreaming :D :) It's not something you could do with an AP officially as they don't see the AST below method level. You could do it by casting to internal implementation types of javac which will give you the full AST down to actual leave nodes. But it's not something I'd feel like doing as it ties you to com.sun.* APIs and won't be portable across compilers. The checker framework ( http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html) helps a bit with it. But the issue remains that it cannot be used with Eclipse's compiler. Probably the best way to address this concern is to not use JP-QL but a strongly typed query DSL altogether. --Gunnar 2017-01-03 12:54 GMT+01:00 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 > >> 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? > > Yes it's the same problem: I wish we could fix that too. > > If only someone here was a expert of annotation processors maybe he > could tell me if I'm dreaming :D > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] ScrollableResults and 6.0
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 >> 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? Yes it's the same problem: I wish we could fix that too. If only someone here was a expert of annotation processors maybe he could tell me if I'm dreaming :D ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] ScrollableResults and 6.0
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 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 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 > 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 > >> Hibernate NoORM Team > >> > >> On 2 January 2017 at 12:42, Steve Ebersole 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 > 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 > >> Hibernate NoORM Team > >> > >> On 27 December 2016 at 22:02, 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 27, 2016 at 3:01 PM Steve Ebersole > >> wrote: > >> > >> > For 6.0 I'd like to also make ScrollableResults parameterized wrt the > >> "row > >> > type". E.g. > >> > > >> > ScrollableResults 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/mai
Re: [hibernate-dev] ScrollableResults and 6.0
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 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? 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 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 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 >> Hibernate NoORM Team >> >> On 2 January 2017 at 12:42, Steve Ebersole 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 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 >> Hibernate NoORM Team >> >> On 27 December 2016 at 22:02, 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 27, 2016 at 3:01 PM Steve Ebersole >> wrote: >> >> > For 6.0 I'd like to also make ScrollableResults parameterized wrt the >> "row >> > type". E.g. >> > >> > ScrollableResults 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
Re: [hibernate-dev] ScrollableResults and 6.0
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 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 > Hibernate NoORM Team > > On 2 January 2017 at 12:42, Steve Ebersole 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 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 > Hibernate NoORM Team > > On 27 December 2016 at 22:02, 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 27, 2016 at 3:01 PM Steve Ebersole > wrote: > > > For 6.0 I'd like to also make ScrollableResults parameterized wrt the > "row > > type". E.g. > > > > ScrollableResults 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
Re: [hibernate-dev] ScrollableResults and 6.0
> 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 Hibernate NoORM Team On 2 January 2017 at 12:42, Steve Ebersole 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 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 >> Hibernate NoORM Team >> >> On 27 December 2016 at 22:02, 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 27, 2016 at 3:01 PM Steve Ebersole >> wrote: >> >> > For 6.0 I'd like to also make ScrollableResults parameterized wrt the >> "row >> > type". E.g. >> > >> > ScrollableResults 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
Re: [hibernate-dev] ScrollableResults and 6.0
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> 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 : > 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 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 > > Hibernate NoORM Team > > > > On 27 December 2016 at 22:02, 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 27, 2016 at 3:01 PM Steve Ebersole > > wrote: > > > > > For 6.0 I'd like to also make ScrollableResults parameterized wrt the > > "row > > > type". E.g. > > > > > > ScrollableResults 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
Re: [hibernate-dev] ScrollableResults and 6.0
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 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 > Hibernate NoORM Team > > On 27 December 2016 at 22:02, 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 27, 2016 at 3:01 PM Steve Ebersole > wrote: > > > For 6.0 I'd like to also make ScrollableResults parameterized wrt the > "row > > type". E.g. > > > > ScrollableResults 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
Re: [hibernate-dev] ScrollableResults and 6.0
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 Hibernate NoORM Team On 27 December 2016 at 22:02, 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 27, 2016 at 3:01 PM Steve Ebersole > wrote: > > > For 6.0 I'd like to also make ScrollableResults parameterized wrt the > "row > > type". E.g. > > > > ScrollableResults 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
Re: [hibernate-dev] ScrollableResults and 6.0
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 wrote: > For 6.0 I'd like to also make ScrollableResults parameterized wrt the "row > type". E.g. > > ScrollableResults 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
