RE: broken indexing

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:51 AM 2002-01-14, Howard Chu wrote:
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>
>> At 03:18 AM 2002-01-14, Howard Chu wrote:
>> >I've got it all working again, but I wonder how smart it is to use it in
>> >general.  ("name" pulls in many other attributeTypes that perhaps don't need
>> >to be indexed.) When indices are stored due to subtyping, they're all
>> >stored in a single database, whereas explicit indexing uses a separate
>> >database per attribute.
>>
>> No!  That's
>>         index name      autosubtypes
>>
>> not
>>         index name      eq,subtypes
>>
>> The latter, which should be the default, allows indices generated
>> for an explicit type to be used by its subtypes.  That is, when
>> search for (cn=foo) and there is no specific index on 'cn',
>> candidates are select as if (name=foo) was asserted.
>>
>> The former, which should NOT be the default, causes indices for
>> name and all of its subtypes to be generated.  This means if
>> cn: foo exists in a entry, there will be keys for both cn: foo
>> name: foo will appear in the index.
>>
>> Likewise for language tag indexing options.
>
>I have corrected my previous patch to support this behavior. I see the
>distinction, but it's a rather slim one. In the autosubtypes case, more
>index files are generated. In the default case, the index for the supertype
>just gets more heavily populated.

I think you are missing part of the distinction, so for clarity:

In 2.0 code,  if one says:
        index attr eq

an equality index is generated for assertions of attr.  If
attr is a supertype of super, then values of super must be
included as if they were values of attr.

In HEAD (and in 2.0 as a non-default "subtypes" feature), there is
an added feature in that if one asserts super and super does not
have its own index, then the index for its supertype (e.g. attr)
is used to generate candidates.  This is the default now as its
believed that supertype index is better than no index.

Then there is "autosubtyping", here one says:
        index attr eq,autosubtypes

and this works as if the user had specified:
        index   attr eq
        index   subtype eq  (for all subtypes of attr)

The difference is that the keys for these are located in
1 DB instead of 1+N DBs.  It differs from the "subtypes"
feature in that separate keys are generates for each subtype.

The usefulness of the "autosubtypes" feature is questionable.
I would have no problem if this feature disappeared.

Kurt