[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: dyngroup return codes

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