[midPoint] - Filter returns same entry multiple times

[Rodrigo Yanis]

Hello Pavol,

Thanks for your clearance. At the extent of our tests, this has been
happening in filtered bulk actions - objects are processed as many times as
they appear on the query result.

Any other information that might help, let me know.

Regards,


*Rodrigo Yanis.*
Identicum S.A.
Jorge Newbery 3226
Tel: +54 (11) 4824-9971
ryanis at identicum.com
www.identicum.com

2017-03-29 18:47 GMT-03:00 Pavol Mederly <mederly at evolveum.com>:

> 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 developerevolveum.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:
>
> [image: 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
> www.identicum.com
>
>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
> _______________________________________________
> 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/20170330/a068eef7/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/20170330/a068eef7/attachment.png>