Re: [hibernate-dev] Some insight about HHH-12101 / remove HQL-style positional parameters

[Laurent Almeras]

Thanks for your feedback.

As I currently use QueryDSL generated queries, it's not easy to switch 
the way my queries are generated.

I post an issue with a github branch with some simple test-cases here: 
https://hibernate.atlassian.net/browse/HHH-12290


Laurent Almeras


Le 07/02/2018 à 19:43, Steve Ebersole a écrit :
> And I did say that this is indeed a problem assuming you are right, 
> and I have no reason to believe you are not.  In fact I can see how 
> that would happen.  Yes all based on Hibernate internals.
>
> So I am not trying to blow you off as "this is not a bug". I think it 
> is a bug.  I'm just saying I do not yet know what to do about it.
>
> On Wed, Feb 7, 2018 at 12:41 PM Steve Ebersole  > wrote:
>
> Yes, I understood the situation.
>
> I'm saying that in your query you should just be able to switch to
> use named parameters (prefixed with `:`, rather than `?`) as a
> workaround
>
> On Wed, Feb 7, 2018 at 11:21 AM Laurent Almeras
> >
> wrote:
>
> Hi,
>
> Thanks for this insight ; but as I stated (and this is a
> correction of the assumptions of my first email) in my second
> email, it seems that the wrong query (with mixed positional
> and named parameters) is built in hibernate inside layers (and
> not in QueryDSL).
>
> I get rid of my QueryDSL query and replace it with raw JPQL
> query :
>
>
> 
>         Query query = getEntityManager().createQuery("select
> queuedTaskHolder\n" +
>                 "from QueuedTaskHolder queuedTaskHolder\n" +
>                 "where queuedTaskHolder.status in (?1) and
> queuedTaskHolder.queueId = ?2\n" +
>                 "order by queuedTaskHolder.id
> asc").setParameter(1, ImmutableList.of(TaskStatus.CANCELLED,
> TaskStatus.COMPLETED)).setParameter(2, "queue");
>         return query.getResultList();
> 
>
> And it fails with the very same message :
>
>
> 
>
>
> Cannot define positional and named parameterSpecs : select
> queuedTaskHolder
> from
> org.iglooproject.jpa.more.business.task.model.QueuedTaskHolder
> queuedTaskHolder
>
> where queuedTaskHolder.status in (:x1_0, :x1_1) and
> queuedTaskHolder.queueId = ?2
> order by queuedTaskHolder.id asc
>     at
> 
> org.hibernate.hql.internal.ast.HqlSqlWalker.generatePositionalParameter(HqlSqlWalker.java:1094)
>     at
> 
> org.hibernate.hql.internal.antlr.HqlSqlBaseWalker.parameter(HqlSqlBaseWalker.java:3463)
> 
>
> It used to work with Hibernate 5.2.x ; and by reading JPQL
> spec (not sure if this is the right version -
> 
> https://docs.oracle.com/html/E13946_01/ejb3_langref.html#ejb3_langref_in
> ) it seems that " IN (?param) " is a valid syntax.
>
> I agree that mixed query may not be supported, but even if
> positional parameter queries bring nothing more than named
> parameters ones, there are also required for JPA compliance ?
>
> Can you say me if I made some wrong assumptions ? If not, is
> it usefull I provide some minimal test-case ?
>
>
>
> *Side-note:* same query written with named parameters is OK
> (as expected):
>
>
> 
>         Query query = getEntityManager().createQuery("select
> queuedTaskHolder\n" +
>         "from QueuedTaskHolder queuedTaskHolder\n" +
>         "where queuedTaskHolder.status in (:statuses) and
> queuedTaskHolder.queueId = :queue\n" +
>         "order by queuedTaskHolder.id
> asc").setParameter("statuses",
> ImmutableList.of(TaskStatus.CANCELLED,
> TaskStatus.COMPLETED)).setParameter("queue", "queue");
>         return query.getResultList();
> 
>
>
>
> Thanks,
>
>
> Le 07/02/2018 à 17:30, Steve Ebersole a écrit :
>> Yes, I can see this being a problem. Its caused by some very
>> old, fulgy code in how "list-valued parameters" are handled
>> internally.
>>
>> I'm not sure the best way to deal with this. Unfortunately
>> reverting this is not possible - its necessary for JPA
>> compliance.  The simple workaround of course is to use named
>> parameters yourself.  Honestly JPA's notion of "positional"
>> parameters is nonsensical since they are not positional - the
>> ordinals can repeat and can appear in any order... nothing
>> particularly positional about that.  In fact they are really
>> nothing more than 

Re: [hibernate-dev] Some insight about HHH-12101 / remove HQL-style positional parameters

[Steve Ebersole]

And I did say that this is indeed a problem assuming you are right, and I
have no reason to believe you are not.  In fact I can see how that would
happen.  Yes all based on Hibernate internals.

So I am not trying to blow you off as "this is not a bug".  I think it is a
bug.  I'm just saying I do not yet know what to do about it.

On Wed, Feb 7, 2018 at 12:41 PM Steve Ebersole  wrote:

> Yes, I understood the situation.
>
> I'm saying that in your query you should just be able to switch to use
> named parameters (prefixed with `:`, rather than `?`) as a workaround
>
> On Wed, Feb 7, 2018 at 11:21 AM Laurent Almeras <
> laurent.alme...@laposte.net> wrote:
>
>> Hi,
>>
>> Thanks for this insight ; but as I stated (and this is a correction of
>> the assumptions of my first email) in my second email, it seems that the
>> wrong query (with mixed positional and named parameters) is built in
>> hibernate inside layers (and not in QueryDSL).
>>
>> I get rid of my QueryDSL query and replace it with raw JPQL query :
>>
>>
>> 
>> Query query = getEntityManager().createQuery("select
>> queuedTaskHolder\n" +
>> "from QueuedTaskHolder queuedTaskHolder\n" +
>> "where queuedTaskHolder.status in (?1) and
>> queuedTaskHolder.queueId = ?2\n" +
>> "order by queuedTaskHolder.id asc").setParameter(1,
>> ImmutableList.of(TaskStatus.CANCELLED,
>> TaskStatus.COMPLETED)).setParameter(2, "queue");
>> return query.getResultList();
>> 
>>
>> And it fails with the very same message :
>>
>>
>> 
>>
>>
>> Cannot define positional and named parameterSpecs : select
>> queuedTaskHolder
>> from org.iglooproject.jpa.more.business.task.model.QueuedTaskHolder
>> queuedTaskHolder
>>
>> where queuedTaskHolder.status in (:x1_0, :x1_1) and
>> queuedTaskHolder.queueId = ?2
>> order by queuedTaskHolder.id asc
>> at
>> org.hibernate.hql.internal.ast.HqlSqlWalker.generatePositionalParameter(HqlSqlWalker.java:1094)
>> at
>> org.hibernate.hql.internal.antlr.HqlSqlBaseWalker.parameter(HqlSqlBaseWalker.java:3463)
>> 
>>
>> It used to work with Hibernate 5.2.x ; and by reading JPQL spec (not sure
>> if this is the right version -
>> https://docs.oracle.com/html/E13946_01/ejb3_langref.html#ejb3_langref_in
>> ) it seems that " IN (?param) " is a valid syntax.
>>
>> I agree that mixed query may not be supported, but even if positional
>> parameter queries bring nothing more than named parameters ones, there are
>> also required for JPA compliance ?
>>
>> Can you say me if I made some wrong assumptions ? If not, is it usefull I
>> provide some minimal test-case ?
>>
>>
>>
>> *Side-note:* same query written with named parameters is OK (as
>> expected):
>>
>>
>> 
>> Query query = getEntityManager().createQuery("select
>> queuedTaskHolder\n" +
>> "from QueuedTaskHolder queuedTaskHolder\n" +
>> "where queuedTaskHolder.status in (:statuses) and
>> queuedTaskHolder.queueId = :queue\n" +
>> "order by queuedTaskHolder.id asc").setParameter("statuses",
>> ImmutableList.of(TaskStatus.CANCELLED,
>> TaskStatus.COMPLETED)).setParameter("queue", "queue");
>> return query.getResultList();
>> 
>>
>>
>>
>> Thanks,
>>
>> Le 07/02/2018 à 17:30, Steve Ebersole a écrit :
>>
>> Yes, I can see this being a problem.  Its caused by some very old, fulgy
>> code in how "list-valued parameters" are handled internally.
>>
>> I'm not sure the best way to deal with this.  Unfortunately reverting
>> this is not possible - its necessary for JPA compliance.  The simple
>> workaround of course is to use named parameters yourself.  Honestly JPA's
>> notion of "positional" parameters is nonsensical since they are not
>> positional - the ordinals can repeat and can appear in any order... nothing
>> particularly positional about that.  In fact they are really nothing more
>> than named parameters that happen to use int-valued labels.
>>
>> Longer term 6.0 will address this because it changes that "old, fulgy"
>> internal code - but those same changes are not possibly in 5.3.
>>
>>
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Some insight about HHH-12101 / remove HQL-style positional parameters

[Steve Ebersole]

Yes, I understood the situation.

I'm saying that in your query you should just be able to switch to use
named parameters (prefixed with `:`, rather than `?`) as a workaround

On Wed, Feb 7, 2018 at 11:21 AM Laurent Almeras 
wrote:

> Hi,
>
> Thanks for this insight ; but as I stated (and this is a correction of the
> assumptions of my first email) in my second email, it seems that the wrong
> query (with mixed positional and named parameters) is built in hibernate
> inside layers (and not in QueryDSL).
>
> I get rid of my QueryDSL query and replace it with raw JPQL query :
>
>
> 
> Query query = getEntityManager().createQuery("select
> queuedTaskHolder\n" +
> "from QueuedTaskHolder queuedTaskHolder\n" +
> "where queuedTaskHolder.status in (?1) and
> queuedTaskHolder.queueId = ?2\n" +
> "order by queuedTaskHolder.id asc").setParameter(1,
> ImmutableList.of(TaskStatus.CANCELLED,
> TaskStatus.COMPLETED)).setParameter(2, "queue");
> return query.getResultList();
> 
>
> And it fails with the very same message :
>
>
> 
>
>
> Cannot define positional and named parameterSpecs : select queuedTaskHolder
> from org.iglooproject.jpa.more.business.task.model.QueuedTaskHolder
> queuedTaskHolder
>
> where queuedTaskHolder.status in (:x1_0, :x1_1) and
> queuedTaskHolder.queueId = ?2
> order by queuedTaskHolder.id asc
> at
> org.hibernate.hql.internal.ast.HqlSqlWalker.generatePositionalParameter(HqlSqlWalker.java:1094)
> at
> org.hibernate.hql.internal.antlr.HqlSqlBaseWalker.parameter(HqlSqlBaseWalker.java:3463)
> 
>
> It used to work with Hibernate 5.2.x ; and by reading JPQL spec (not sure
> if this is the right version -
> https://docs.oracle.com/html/E13946_01/ejb3_langref.html#ejb3_langref_in
> ) it seems that " IN (?param) " is a valid syntax.
>
> I agree that mixed query may not be supported, but even if positional
> parameter queries bring nothing more than named parameters ones, there are
> also required for JPA compliance ?
>
> Can you say me if I made some wrong assumptions ? If not, is it usefull I
> provide some minimal test-case ?
>
>
>
> *Side-note:* same query written with named parameters is OK (as expected):
>
>
> 
> Query query = getEntityManager().createQuery("select
> queuedTaskHolder\n" +
> "from QueuedTaskHolder queuedTaskHolder\n" +
> "where queuedTaskHolder.status in (:statuses) and
> queuedTaskHolder.queueId = :queue\n" +
> "order by queuedTaskHolder.id asc").setParameter("statuses",
> ImmutableList.of(TaskStatus.CANCELLED,
> TaskStatus.COMPLETED)).setParameter("queue", "queue");
> return query.getResultList();
> 
>
>
>
> Thanks,
>
> Le 07/02/2018 à 17:30, Steve Ebersole a écrit :
>
> Yes, I can see this being a problem.  Its caused by some very old, fulgy
> code in how "list-valued parameters" are handled internally.
>
> I'm not sure the best way to deal with this.  Unfortunately reverting this
> is not possible - its necessary for JPA compliance.  The simple workaround
> of course is to use named parameters yourself.  Honestly JPA's notion of
> "positional" parameters is nonsensical since they are not positional - the
> ordinals can repeat and can appear in any order... nothing particularly
> positional about that.  In fact they are really nothing more than named
> parameters that happen to use int-valued labels.
>
> Longer term 6.0 will address this because it changes that "old, fulgy"
> internal code - but those same changes are not possibly in 5.3.
>
>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Some insight about HHH-12101 / remove HQL-style positional parameters

[Steve Ebersole]

Yes, I can see this being a problem.  Its caused by some very old, fulgy
code in how "list-valued parameters" are handled internally.

I'm not sure the best way to deal with this.  Unfortunately reverting this
is not possible - its necessary for JPA compliance.  The simple workaround
of course is to use named parameters yourself.  Honestly JPA's notion of
"positional" parameters is nonsensical since they are not positional - the
ordinals can repeat and can appear in any order... nothing particularly
positional about that.  In fact they are really nothing more than named
parameters that happen to use int-valued labels.

Longer term 6.0 will address this because it changes that "old, fulgy"
internal code - but those same changes are not possibly in 5.3.


On Fri, Feb 2, 2018 at 3:37 PM Laurent Almeras  wrote:

> Hi,
>
> After digging further, it seems to me that there is a bug with Hibernate
> 5.3.
>
> I debug and step through the query handling, and the generated QueryDSL
> query seems correct to me:
>
> =
> select queuedTaskHolder
> from QueuedTaskHolder queuedTaskHolder
> where queuedTaskHolder.status in (?1) and queuedTaskHolder.queueId = ?2
> order by queuedTaskHolder.id asc
> =
>
> The (:x1_0, :x1_1, :x1_2, :x1_3) part appears in the hibernate query
> handling inside layers, in
>
> org.hibernate.query.internal.QueryParameterBindingsImpl.expandListValuedParameters(String,
> SharedSessionContractImplementor) method. It seems that the purpose of
> this method is to transform query and parameters arguments when argument
> is a list. So query is rewritten with named parameters, and query
> parameters are modified to inject this new parameters.
>
> And this query is then rejected in
>
> org.hibernate.hql.internal.ast.HqlSqlWalker.generatePositionalParameter(AST,
> AST) because there are namedParameters.
>
> If I switch dependency to 5.2.12.Final release, the same code works.
>
> I'll try to write a minimal test-case about this when I'll get some
> spare time.
>
> --
> Laurent Almeras
>
> On 02/02/2018 06:00 PM, Laurent Almeras wrote:
> > Hi,
> >
> > Testing Hibernate 9.3.0.Beta2, I run into this issue:
> >
> >
> > ===
> >   Cannot define positional and named parameterSpecs : select
> > queuedTaskHolder
> > from org.iglooproject.jpa.more.business.task.model.QueuedTaskHolder
> > queuedTaskHolder
> > where queuedTaskHolder.status in (:x1_0, :x1_1, :x1_2, :x1_3) and
> > queuedTaskHolder.queueId = ?2
> > ===
> >
> >
> > Hibernate complains that query contains both named and positional
> > parameters (note that this query use to work on Hibernate 5.2.x).
> >
> > This new behavior is linked to:
> >
> > * this commit:
> >
> https://github.com/hibernate/hibernate-orm/commit/5e0274adbbd3e0aa3092c29a765fd203c8279126
> >
> > * this issue: https://hibernate.atlassian.net/browse/HHH-12116
> > * and this parent issue:
> https://hibernate.atlassian.net/browse/HHH-12101
> >
> > I also find that you already talk about this behavior on this same
> > mailing-list:
> >
> http://lists.jboss.org/pipermail/hibernate-dev/2016-September/015460.html
> >
> >
> > I think that allowing this behavior was not a good idea, so I don't have
> > any hope that you consider this as a bug. But I think it should be
> > noticed in the release note
> > (http://in.relation.to/2018/01/18/hibernate-orm-530-beta1-release/) or
> > in this ticket (https://hibernate.atlassian.net/browse/HHH-12101) as a
> > side-effect.
> >
> >
> > On my side, I run in this issue because I use QueryDSL-jpa, and the
> > query I give as an example is buggy because it mixes a IN statement
> > (named parameter) dans an EQUAL statement (positional parameter).
> >
> > Is there anyone following both Hibernate and QueryDSL here that is
> > already aware or working on this issue ?
> >
> >
> > Thanks
> >
> > Laurent Almeras
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Some insight about HHH-12101 / remove HQL-style positional parameters

[Laurent Almeras]

Hi,

After digging further, it seems to me that there is a bug with Hibernate 
5.3.

I debug and step through the query handling, and the generated QueryDSL 
query seems correct to me:

=
select queuedTaskHolder
from QueuedTaskHolder queuedTaskHolder
where queuedTaskHolder.status in (?1) and queuedTaskHolder.queueId = ?2
order by queuedTaskHolder.id asc
=

The (:x1_0, :x1_1, :x1_2, :x1_3) part appears in the hibernate query 
handling inside layers, in 
org.hibernate.query.internal.QueryParameterBindingsImpl.expandListValuedParameters(String,
 
SharedSessionContractImplementor) method. It seems that the purpose of 
this method is to transform query and parameters arguments when argument 
is a list. So query is rewritten with named parameters, and query 
parameters are modified to inject this new parameters.

And this query is then rejected in 
org.hibernate.hql.internal.ast.HqlSqlWalker.generatePositionalParameter(AST, 
AST) because there are namedParameters.

If I switch dependency to 5.2.12.Final release, the same code works.

I'll try to write a minimal test-case about this when I'll get some 
spare time.

-- 
Laurent Almeras

On 02/02/2018 06:00 PM, Laurent Almeras wrote:
> Hi,
> 
> Testing Hibernate 9.3.0.Beta2, I run into this issue:
> 
> 
> ===
>   Cannot define positional and named parameterSpecs : select 
> queuedTaskHolder
> from org.iglooproject.jpa.more.business.task.model.QueuedTaskHolder 
> queuedTaskHolder
> where queuedTaskHolder.status in (:x1_0, :x1_1, :x1_2, :x1_3) and 
> queuedTaskHolder.queueId = ?2
> ===
> 
> 
> Hibernate complains that query contains both named and positional 
> parameters (note that this query use to work on Hibernate 5.2.x).
> 
> This new behavior is linked to:
> 
> * this commit: 
> https://github.com/hibernate/hibernate-orm/commit/5e0274adbbd3e0aa3092c29a765fd203c8279126
>  
> 
> * this issue: https://hibernate.atlassian.net/browse/HHH-12116
> * and this parent issue: https://hibernate.atlassian.net/browse/HHH-12101
> 
> I also find that you already talk about this behavior on this same 
> mailing-list: 
> http://lists.jboss.org/pipermail/hibernate-dev/2016-September/015460.html
> 
> 
> I think that allowing this behavior was not a good idea, so I don't have 
> any hope that you consider this as a bug. But I think it should be 
> noticed in the release note 
> (http://in.relation.to/2018/01/18/hibernate-orm-530-beta1-release/) or 
> in this ticket (https://hibernate.atlassian.net/browse/HHH-12101) as a 
> side-effect.
> 
> 
> On my side, I run in this issue because I use QueryDSL-jpa, and the 
> query I give as an example is buggy because it mixes a IN statement 
> (named parameter) dans an EQUAL statement (positional parameter).
> 
> Is there anyone following both Hibernate and QueryDSL here that is 
> already aware or working on this issue ?
> 
> 
> Thanks
> 
> Laurent Almeras
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev