RE: indexing objectclass: why?

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]

> At 03:19 PM 2001-11-29, Howard Chu wrote:
> >I noticed this in the back-bdb code, didn't realize it was also in
> >back-ldbm. In back-bdb I've optimized this a bit by scanning the
> user filter
> >in advance, looking for any instances of objectClass in the
> filter (besides
> >objectClass present). If none are found, the alias and referral
> filters are
> >omitted. I think this change should probably go into back-ldbm as well.

> That sounds like a bug?  Even where (objectClass=fubar) was asserted,
> (objectClass=referral) and (objectClass=alias) clauses cannot ommitted
> until ManageDsaIt is set or aliasing derefering is disabled, respectively.

Perhaps I wasn't clear enough. If objectClass is never mentioned in a user
filter, or if the only mention is objectClass=*, the alias/referral clauses
are omitted. If objectClass is used in the filter in any other way, the
clauses are included as before.

> >On a side note, I actually created a presence index for
> objectClass, which
> >turned out to be a silly thing to do. Creating such huge ID
> lists makes the
> >objectClass index database very inefficient. The backend
> probably ought to
> >silently ignore if this appears in a .conf file, and just
> implicitly return
> >a match on the entire database for this filter.
>
> We really should hard code "index objectClass eq" and disallow changes.

Makes sense.