+1 to default of 1.
On Fri, Sep 23, 2016 at 8:50 AM, Steve Ebersole wrote:
> I did end up adding support for controlling this via a setting[1]. Now,
> when recognizing ordinal parameters (as distinct from positional
> parameters, i.e. ?1) we define the "base" as:
>
>if ( factory.getSessionF
I did end up adding support for controlling this via a setting[1]. Now,
when recognizing ordinal parameters (as distinct from positional
parameters, i.e. ?1) we define the "base" as:
if ( factory.getSessionFactoryOptions().isJpaBootstrap() ) {
ordinalParameterBase = 1;
}
else {
Well therein lies (yet another) minor rub
On Thu, Sep 22, 2016 at 7:06 AM Steve Ebersole wrote:
> Well therein lies a minor rub in having split SQM out from ORM.
> Specifically if the "compliance violation" occurs in the HQL/JPQL/Criteria
> query the exception is a type from SQM (it has no d
Well therein lies a minor rub in having split SQM out from ORM.
Specifically if the "compliance violation" occurs in the HQL/JPQL/Criteria
query the exception is a type from SQM (it has no deps on ORM). Here
though it is not reasonable to throw an SQM exception type.
On Wed, Sep 21, 2016 at 2:
That sounds reasonable. So long as there is a property to control it from
persistence.xml, more people will be happy with it.
It would be very important to quote whatever error people will get in the
docs, so they can find the solution easier.
2016-09-21 22:03 GMT+03:00 Steve Ebersole :
> One ad
One additional thing we might consider is possibly unifying this 0- and 1-
based mismatch wrt JDBC-style parameters.
In Hibernate's APIs these JDBC-style parameters were 0-based. I have
already dropped support (it has been deprecated for a long time anyway) for
using JDBC-style params in HQL. So
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,
+1
On 09/20/2016 08:59 PM, Steve Ebersole wrote:
> 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
+1
On 21 Sep 2016 02:00, "Steve Ebersole" wrote:
> 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 onl
+1 Sounds good.
2016-09-21 2:59 GMT+02:00 Steve Ebersole :
> 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.
>
+1
On Wed, Sep 21, 2016 at 3:59 AM, Steve Ebersole wrote:
> 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.
>
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 E
+1 across the board.
On 09/20/2016 08:59 PM, Steve Ebersole wrote:
> 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
> parame
13 matches
Mail list logo
