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 <st...@hibernate.org > <mailto:st...@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.alme...@laposte.net <mailto: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