I ended up changing the default to 1 for consistency, but adding a setting
`hibernate.query.sql.jdbc_style_params_base` upgrading users can use
temporarily.
On Mon, Nov 20, 2017 at 4:01 AM andrea boriero wrote:
> I would prefer consistency, but as you pointed out this for users will be
> another
I would prefer consistency, but as you pointed out this for users will be
another upgrade concer , so may be for a 5.3 it is better to mantain the
zero-based style.
On 18 November 2017 at 19:18, Steve Ebersole wrote:
> Another thing that comes up is parameters and native queries. In native
> qu
Another thing that comes up is parameters and native queries. In native
queries, all 3 forms are valid: named, jpa-ordinal and jdbc-style.
Again historically all positional (jdbc-style) parameters are zero-based.
This open up the problem of different bases depending on whether jpa-style
or jdbc-s
+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
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
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
