> On 13 Dec 2014, at 08:08, Rich Megginson <[email protected]> wrote:
> 
>> On 12/12/2014 02:27 PM, William B wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>>>>>> What is the default behaviour if no equality type is defined?
>>>  From http://tools.ietf.org/html/rfc4512
>>> "
>>> 
>>>     If no equality matching is specified for the attribute type:
>>> 
>>>        - the attribute (of the type) cannot be used for naming;
>>>        - when adding the attribute (or replacing all values), no two
>>>          values may be equivalent (see 2.2);
>>>        - individual values of a multi-valued attribute are not to be
>>>          independently added or deleted;
>>>        - attribute value assertions (such as matching in search
>>> filters and comparisons) using values of such a type cannot be
>>>          performed."
>>> 
>>> Which means, you are not supposed to use it in a search filter.
>> 
>> Ahh that's good to know. This kind of thing should be in the RHDS 
>> documentation
>> as we couldn't find anything about the topic, and it's an invaluable piece of
>> knowledge in solving this issue.
> 
> There is a _lot_ of information in the LDAP RFCs that is not in the RHDS 
> documentation . . .
> 

While that may be the case, I would like to see clearly in the indexing section 
a description, even brief, of the behaviour when an index with equality is set. 
Link to the rfc for detailed description even.

Perhaps also a warning in the errors file when such an index is created / at 
start up?


>> 
>>> However, 389 provides a default equality matching rule, which is
>>> essentially a memcmp(3).  When you create an index, it attempts to
>>> use the equality matching rule to create the equality index.  I guess
>>> the indexing code is getting confused.  Do you have
>>> a /var/lib/dirsrv/slapd-INST/db/userRoot/maildeliveryoption.db4
>>> file?  If so, does it have anything in it?  dbscan
>>> -f /var/lib/dirsrv/slapd-INST/db/userRoot/maildeliveryoption.db4
>> The db4 file in question was empty. I am assuming that this indicates an 
>> issue
>> with the indexing yielding no data, but if it was empty, and an index search 
>> was
>> performed I am assuming that is why our search begins to return no data.
> 
> Correct.

Thank you. I appreciate your help and advice.

Sincerely

William

--
389 users mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/389-users

Reply via email to