Re: Resolving groups (neophyte question)

[Mark Smith <mcs@netscape.com>]

All of this is implementation dependent, but I would agree that
evaluating presence filters should be very efficient since there is no
need to look at individual values -- as you say, it is enough to check
that at least one value exists for the attribute.

It is standard practice for LDAP clients to use the filter
"(objectclass=*)" when reading entries; so much so that this has been
baked into recent C LDAP API Internet Drafts such that passing NULL for
the filter argument to the ldap_search() functions means 'use the filter
"(objectclass=*)".'

Also, the U-M LDAP 3.3 slapd and most of its descendants -- including
our Netscape Directory Server -- do maintain an equality index for the
objectclass attribute.  This is baked into the LDBM database backend and
there is no way to disable the index.  Objectclass is a fundamental
attribute type and is used internally by the server for various things.

-- 
Mark Smith
Netscape Communications Corp. / Directory Server Engineering
"Got LDAP?"


Gary Williams wrote:
> 
> I realize this is getting off the original topic, but I always
> thought a '=*' test was the most efficient since it's the
> "presence" operator.  Rather than having to compare the value
> of the attribute against a value, once the server determines
> it's there, the test is true.
> 
> -----Original Message-----
> From: Mark Wilcox [mailto:mark@mjwilcox.com]
> Sent: Tuesday, June 08, 1999 10:10 PM
> To: Jeff Clowser; openldap-general@OpenLDAP.org
> Subject: Re: Resolving groups (neophyte question)
> 
> Hi,
> anything that is specific (eg. objectclass=inetorgperson) is always more
> effecient than a wildcard, in particular anything that can be anything
> (because objectclass isn't indexed this can be doubly so ;)
> 
> Mark
> -----Original Message-----
> From: Jeff Clowser <jclowser@aerotek.com>
> To: openldap-general@OpenLDAP.org <openldap-general@OpenLDAP.org>
> Date: Tuesday, June 08, 1999 4:03 PM
> Subject: Re: Resolving groups (neophyte question)
> 
> >I coulda sworn I did this before a long time ago, and it worked (maybe
> Netscape DS 3.x),
> >but it's a really ugly way to do it, and given that the dn is kinda
> "special", I completely
> >agree that it's at least bad form.
> >
> >Definately the best way to go is to use the known dn as the base dn, scope
> of base,  and
> >a filter of objectclass=*.  Actually, does anyone know if it would be more
> or less efficient
> >to use objectclass=* vs. objectclass=inetorgperson or whatever objectclass
> would
> >further restrict it? - I usually just use objectclass=*, but I wonder if
> objectclass=inetorgperson
> >is more efficient, or if it makes it do further comparisions that would
> slow things down.
> >
> >-Jeff
> >
> >Julio Sánchez Fernández wrote:
> >
> >> Jeff Clowser wrote:
> >> >
> >> > Try this:
> >> > ldapsearch -v -L -s sub  -b 'o=mirapoint.com' -h ugh
> 'dn=uid=bryan,ou=People, o=mirapoint.com'
> >> >
> >> > (Note the dn=uid=...)
> >>
> >> If that works, then it is another unintended side-effect of the way
> OpenLDAP
> >> deals with the DN (treats it as an attribute).  I don't think this is
> >> required behaviour.  And as a matter of fact, future changes to OpenLDAP
> are
> >> likely to break this.  I have my eyes put on some changes that could make
> >> the DN disappear as an attribute of the entry.  So if anyone can provide
> >> any proof that this is required behaviour, please speak up before I make
> a
> >> fool of myself by breaking it.
> >>
> >> > Probably a more efficient way would be to make the scope
> >> > same (-s same?)
> >>
> >> -s base
> >>
> >> Julio
> >
> >--
> > Jeff Clowser
> > mailto:jclowser@aerotek.com       Hanover MD  21076 USA
> > Phone: (410)-579-4328             7312 Parkway Drive