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 ch
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 2
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 fin
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
> 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
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
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 i
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 actuall
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. Tod
> 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 th
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 su
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
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 onl
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
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
15 matches
Mail list logo
