10:01 p.m.
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?
10:02 p.m.
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?
9:35 a.m.
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
12:42 p.m.
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
1:17 p.m.
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 =
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 <steve(a)hibernate.org>:
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
>
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2:11 p.m.
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
>>
>>
>>
3:09 p.m.
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
11:57 a.m.
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 <steve(a)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(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
>
>
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
12:39 p.m.
2017-01-03 11:57 GMT+01:00 Sanne Grinovero <sanne(a)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(a)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(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
>>
>>
>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
12:54 p.m.
On 3 January 2017 at 11:39, Gunnar Morling <gunnar(a)hibernate.org> wrote:
2017-01-03 11:57 GMT+01:00 Sanne Grinovero
<sanne(a)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?
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
1:13 p.m.
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-framewor...)
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 <sanne(a)hibernate.org>:
> On 3 January 2017 at 11:39, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> > 2017-01-03 11:57 GMT+01:00 Sanne Grinovero <sanne(a)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?
>
> 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
>
3:37 p.m.
Inline...
On Tue, Jan 3, 2017 at 4:58 AM Sanne Grinovero <sanne(a)hibernate.org> 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<Object[]> results = session.createQuery( "select p.name.first,
p.name.last from Person p" ).list();
vs.
ScrollableResults<Object[]> results = session.createQuery( "select
p.name.first, p.name.last from Person p" ).scroll();
or using Tuples if you prefer:
List<Tuple> results = session.createQuery( "select p.name.first,
p.name.last from Person p", Tuple.class ).list();
vs.
ScrollableResults<Tuple> 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...
3:45 p.m.
Inline...
On Tue, Jan 3, 2017 at 5:39 AM Gunnar Morling <gunnar(a)hibernate.org> wrote:
2017-01-03 11:57 GMT+01:00 Sanne Grinovero
<sanne(a)hibernate.org>:
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<Tuple>#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<Tuple> 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[]...
9:39 p.m.
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 <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
12:54 p.m.
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 <crancran(a)gmail.com> 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 <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
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2664
days inactive
2677
days old
14 comments
6 participants
participants (6)
-
Chris Cranford -
Gunnar Morling -
Sanne Grinovero -
Steve Ebersole -
Vlad Mihalcea -
Yoann Rodiere