[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.