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 <coladict(a)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 <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