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
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
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
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?
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
>>
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
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
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
> 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
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
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
11 matches
Mail list logo