[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: dyngroup return codes
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.