[midPoint] <not> clause breaking xml query (midpoint 3.6)

[Alcides Carlos de Moraes Neto]

So, this only happens with multivalued fields. Single valued fields work
just fine. Is this as intended?

2017-09-28 18:51 GMT-03:00 Alcides Carlos de Moraes Neto <
alcides.neto at gmail.com>:

> Hello all,
>
> I'm trying to make a simple search query. I want to find all users with an
> assignment, that don't have XYZ value for organizational unit.
>
> I can do this just fine:
> <query>
>     <filter>
>         <and>
>             <ref>
>                 <path>assignment/targetRef</path>
>                 <value oid="7d66fc64-1540-44da-8f3d-c565bc917e12"/>
>             </ref>
>             <equal>
>                 <path>organizationalUnit</path>
>                 <value>XYZ</value>
>             </equal>
>         </and>
>     </filter>
> </query>
>
> This will fetch users with the assignment and the value organizationalUnit
> XYZ
>
> If I add the <not>...
> <query>
>     <filter>
>         <and>
>             <ref>
>                 <path>assignment/targetRef</path>
>                 <value oid="7d66fc64-1540-44da-8f3d-c565bc917e12"/>
>             </ref>
>             <not>
>               <equal>
>                   <path>organizationalUnit</path>
>                   <value>NQPPPS</value>
>               </equal>
>             </not>
>         </and>
>     </filter>
> </query>
>
>
> This results in a hibernate error:
> org.hibernate.HibernateException: SqlNode's text did not reference
> expected number of columns at org.hibernate.hql.internal.ast.tree.
> AbstractNullnessCheckNode.extractMutationTexts(AbstractNullnessCheckNode.
> java:151)
> ...
> at com.evolveum.midpoint.repo.sql.query2.hqm.RootHibernateQuery.
> getAsHqlQuery(RootHibernateQuery.java:96)
>
> Am I doing something wrong? Is it a bug? I'm using midpoint 3.6
> Is there any other way to get what I want from a query?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20171002/a38e5643/attachment.htm>