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 <steve(a)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
parameters.
JPA only defines support for "JDBC-style parameters" as valid for native
SQL queries:
{quote}
It is assumed that for native queries the parameters themselves use the SQL
syntax (i.e., “?”, rather than “?1”).
{quote}
Furthermore Hibernate does not support a native query using both positional
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
indicated.
Anyone have objections to any of that?
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev