[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: What indexes are allowed ? [auf Viren überprüft]

> I think, we should add a hint to the Administrator's Guide /
> faq-o-matic, that
> a) One can only set index-types, which are defined in the schema.
> and
> b) One can only use index-types, which use the implemented matching rules.

The FAQ is interactive; feel free to add a contribution.

> So the hint should be something like this:
> "You can't use indexes on attributes, that require one of the following
> matching rules (defined in the schema):
> - caseIgnoreListMatch
> - caseIgnoreListSubstringsMatch
> E.g. for attribute homePostalAddress in cosine.schema index eq and sub
> cannot be set.
> attributetype ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress'
>            DESC 'RFC1274: home postal address'
>            EQUALITY caseIgnoreListMatch
>            SUBSTR caseIgnoreListSubstringsMatch
>            SYNTAX )"
> Please correct me, of I'm wrong.

Sounds correct.

>> i.e. there's no match function associated to the matching rules; as
>> such, matching on those values is not implemented.
> Are there other matching rules, that are not implemented?

I don't know, I should look into the code a bit more carefully.  Anywhere
there's no "match" hook in a matching rule, that's incomplete.

>> Concerning the reason, I believe it's because there's never been any
>> real push to implement them.  Feel free to contribute a patch (thru
>> the ITS <http://www.openldap.org/its/> and conforming to the
>> contribution guidelines
>> <http://www.openldap.org/devel/contributing.html>).
> I'm not a developer, so I think  I won't write a patch.
> Can I - as a work around - change the schema to use other (similar)
> matching rules to get a working index?

Changing standard track schema is considered bad practice; the fact that
schema is somehow broken or, like in this case, not implemented, should
not be viewed as a good reason.  Maybe you could work at the code side,
using some "safe" replacement for the missing hook.  octetStringMatch
could be overconservative, but at least it would allow you to add/delete
values.  caseIgnoreStrings could be too liberal.  I suggest you choose
whatever better complies with your needs.


Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team

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