[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 <steve at hibernate.org> 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.almeras at 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.
>>
>>
>>
>>