[Date Prev][Date Next]
RE: indexing objectclass: why?
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.