Guys "position rather than alias usage in JDBC" is a small part of a
massive set of related changes in how we build SQL and consume the
results. And actually it is the piece that has any compatibility impact
since it means any and all custom Types will need to be re-written.
On Fri, May 29, 2015 at 5:53 AM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
I agree as well :)
Just to add a minor twist:
- the override to lazy from eager would be useful to Search; skipping
fields completely as an extra bonus (something I think ORM can't do at
all - for good reasons when it comes to end user API - but again
something Search would benefit from and not expose to users).
- since I'm currently exploring the 2nd level cache keys and the
persistence context keys again, it's getting clear (again as we
discussed this before) to potentially use a different data structure
to hold the persistence context.
But neither is urgent, I'd prefer you to schedule things to minimize
overall effort (maximize overall throughput over latency of any of
these).
On "position rather than alias usage in JDBC": I was looking forward
for that as well. Wasn't it part of the 5.0 schedule? I thought it was
done.
Sanne
On 29 May 2015 at 11:22, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
> On Thu, May 28, 2015 at 11:33:22AM -0500, Steve Ebersole wrote:
>> Anyone have any input here? Or should I just start scheduling them how
I
>> want?
>
> I think all goals sound good. I would say schedule as you seem fit, maybe
> with a focus of giving users something tangible asap (a bit of what
Emmanuel
> says).
>
> --Hardy
>
> _______________________________________________
> 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