Re: dyngroup return codes

[Howard Chu <hyc@symas.com>]

Aaron Richton wrote:

> Only hooking on NoSuchAttribute makes sense. My concern is in the
> effectively different answers from the end user perspective. If I run
>
> ldapcompare cn=aEqualsB a:a
>
> on an entry with "a: b", then I get FALSE.
>
> If I set up a dyngroup with (a=a) as the condition, and run
>
> ldapcompare cn=dyngroupAEqualsA member:"cn=aEqualsB"
>
> then I get back the NoSuchAttribute (that was originally assigned by the
> compare operation on dyngroupAEqualsA, as you point out). But when I'm
> running that query, I really don't care about running a compare on
> dyngroupAEqualsA if I'm an end user, I care about entry aEqualsB -- which
> makes more sense, to me, to be FALSE since aEqualsB contains attribute a.
>
> Bottom line:
>
> ldapcompare cn=dyngroupAEqualsA member:"cn=aEqualsB"
> gives me data about dyngroupAEqualsA
>
> ldapcompare cn=dyngroupAEqualsA member:"cn=aEqualsA"
> gives me data about aEqualsA
>
> The fact that one of these acts on the DN, and the other acts on the
> value, is confusing.
I think I see what you're getting at:

The Compare operation is asking - is "someDN" a member of "dynGroup"? If 
we see that the target entry is in fact a dynamic group, then the result 
should be TRUE or FALSE, and not NoSuchAttribute. If the target entry is 
not a dynamic group, i.e., is missing the URI attribute of interest, 
then we can ignore it as before.

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support