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 <lalmeras(a)gmail.com> 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/5e0274adbbd3e0aa3092c29...
>
> * 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev