I have clarified on HHH-10418, but I'll repeat the back-port portion: imo
it is a bad idea to back-port this.
In general I'd say that HHH-10418 should be closed as out-of-date as of 5.2
On Fri, Nov 17, 2017 at 12:29 AM Gail Badner wrote:
> I see that HHH-11356 is scheduled for 6.0.0.Beta1. Any
I wont bore everyone with the history here, but long story short is that we
need to start treating JPA "positional" parameters as positional in the
`javax.persistence.Parameter#getPosition` sense. Even though there is
nothing positional about JPA's positional parameters, this has moved from a
phil
Actually its possible that the TCK always tested it and merging
`javax.persistence.Query` and `org.hibernate.query.Query` may be the
culprit. But either way, the net result is the same...
On Fri, Nov 17, 2017 at 8:44 AM Steve Ebersole wrote:
> I wont bore everyone with the history here, but lon
I think for 5.3 it's still fine to rely on isJpaBootstrap may be
documenting that a SF obtained from unwrapping an EMF will conform to the
JPA spec in term of exceptions.
On 16 November 2017 at 21:09, Vlad Mihalcea wrote:
> When I said multiple modes, I was thinking of defining all these situat
no objections
On 17 November 2017 at 14:44, Steve Ebersole wrote:
> I wont bore everyone with the history here, but long story short is that we
> need to start treating JPA "positional" parameters as positional in the
> `javax.persistence.Parameter#getPosition` sense. Even though there is
> not
+1 I see no problem either.
On 17 November 2017 at 15:57, Steve Ebersole wrote:
> Actually its possible that the TCK always tested it and merging
> `javax.persistence.Query` and `org.hibernate.query.Query` may be the
> culprit. But either way, the net result is the same...
>
> On Fri, Nov 17, 2
