I never said anything about dropping support for named and positional
parameters in native queries.
I simply mentioned leveraging the new "JPA strict compliance" stuff I am
adding to 6.0. The idea is to allow you to enable that and get feedback
when you use non-portable things.
On Tue, Sep 20, 2016 at 11:45 PM Jordan Gigov <colad...@gmail.com> wrote:
> Actually JPA defines it as "Only positional parameter binding and
> positional access to result items may be portably used for native queries".
> I believe "portably" means the providers are only required to support
> positional, but not forbidden from supporting other.
> 2016-09-21 3:59 GMT+03:00 Steve Ebersole <st...@hibernate.org>:
>> In the interest of questioning everything, just to make sure we are all on
>> the same page, Hibernate's support for native SQL queries currently
>> recognizes named parameters, positional parameters as well as JDBC-style
>> JPA only defines support for "JDBC-style parameters" as valid for native
>> SQL queries:
>> It is assumed that for native queries the parameters themselves use the
>> syntax (i.e., “?”, rather than “?1”).
>> Furthermore Hibernate does not support a native query using both
>> parameters and JDBC-style parameters in the same query because it causes a
>> non-determinism wrt the positions.
>> I assume we want to continue to support that full complement of parameter
>> types, with the positional/JDBC-style caveat.
>> Further I assume we will hook up the use of any non-JDBC-style parameters
>> in with the "strict JPA compliance" checking and throw an error when
>> Anyone have objections to any of that?
>> hibernate-dev mailing list
hibernate-dev mailing list