Re: (ITS#4224) compareFalse vs. noSuchobject

[ando@sys-net.it]

On Tue, 2005-11-29 at 03:48 +0000, richton@nbcs.rutgers.edu wrote:
> As a historical note, we've played this game before; I'm not sure if
> anybody cares to analyze how/why/when it fell out, but I recall that
> following
> 
> http://www.openldap.org/lists/openldap-devel/200505/msg00004.html
> 
> there was an actual code change.

Thanks for the pointer; I didn't recall that thread.  In any case, here
the case is a little bit different: the error code was noSuchObject
because the asserted value did not exist.  To stay with your example:

ldapcompare "cn=dyngroup" member:"cn=aEqualsA"

returned noSuchObject if "cn=aEqualsA" if "cn=aEqualsA" did not exist,
regardless of being or not a member of "cn=dyngroup" (in fact, if it
doesn't exist it cannot be member, because those are computed from the
results of an internal search.  However, this is not the point when we
consider the semantics of a compare).

In my opinion, the simple fact that any URI-valued attribute that
correctly expands into a valid search, even if that search is empty
(i.e. the search must not return noSuchObject) should cause a compare
for that group to return at least compareFalse, because the search is
able, in principle, to return a non-empty set of members.

The only open point is about the filter. An incorrect, or an
"impossible" filter (e.g. "(|)") could be treated as noSuchAttribute,
because that search is structurally going to return an empty set of
values.  But I think this point is moot.

p.




Ing. Pierangelo Masarati
Responsabile Open Solution

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------