RE: indexing objectclass: why?

["Kurt D. Zeilenga" <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.

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