[midPoint] - Filter returns same entry multiple times

[Pavol Mederly]

Hello Rodrigo,

this is a known issue, and the one that is not easily resolvable. (It is 
recorded in JIRA, maybe in various contexts, like MID-3293 
<https://jira.evolveum.com/browse/MID-3293>).

I'm afraid we will not be able to fix this in 3.6.

A partial relief could be using the "exists" clause, i.e.

<query>
     <filter>
         <exists>
             <path>assignment</path>
             <filter>
                 <or>
                     <ref>
<path>targetRef</path>
                         <value oid="00000000-0000-0000-0000-000000000004"/>
                     </ref>
                     <ref>
<path>targetRef</path>
                         <value oid="00000000-0000-0000-0000-000000000008"/>
                     </ref>
                 </or>
             </filter>
         </exists>
     </filter>
</query>

But it still returns two results if the user has both assignments.

In midPoint, we do a manual "deduplication" of results at various 
places. Also, there's an experimental "distinct" option in our 
repository API, since 3.6. (But currently it is not available from the 
outside.)

In what context do you have this problem? Is it in bulk actions? Or some 
other task?

Pavol Mederly
Software developer
evolveum.com

On 29.03.2017 23:07, Rodrigo Yanis wrote:
> Hello everyone,
>
> We've been reproducing an issue with midpoint's querying/filtering of 
> objects where, upon executing a query like the following, and 
> expecting only one result for it, we get that result but multiple times.
>
>     <query>
>         <filter>
>             <or>
>                 <ref>
>     <path>assignment/targetRef</path>
>                     <value oid="00000000-0000-1de4-0004-000000000006"/>
>                 </ref>
>                 <ref>
>     <path>assignment/targetRef</path>
>                     <value oid="00000000-0000-1de4-0004-000000000061"/>
>                 </ref>
>             </or>
>         </filter>
>     </query>
>
>
> So in this case only one object satisfies that condition, yet the 
> output is the following:
>
> Imagen integrada 1
>
> At first we thought this might have been a view issue, but then we 
> tested it on a custom task's filter, and the result was that the same 
> user was processed 3 times (or more in other examples), making this 
> type of queries a no-go for performance-intensive processes.
>
> Is this the right way to approach a query like this? Or perhaps 
> there's already a JIRA ticket for this...
>
> Regards,
>
> *Rodrigo Yanis.*
> Identicum S.A.
> Jorge Newbery 3226
> Tel: +54 (11) 4824-9971
> ryanis at identicum.com <mailto:ryanis at identicum.com>
> www.identicum.com <http://www.identicum.com/>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20170329/4958ec1d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 11223 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20170329/4958ec1d/attachment.png>