yes, the index was created, but an index is always only a means to
improve performance of a specific operation, not a functional part.
if you have an attribute with a specific syntax and a default
matching rule you can use anotehr one, but you need to tell the
server which matching rule to use in the search filter. Otherwise
teh default on ewill be used. On extra index can speed up the use of
an alternative MR.
so the search filter shoud look somehow like:
"(memberuid:<mr-oid>:=c12345)"
On 08/10/2018 03:29 PM, Patrick Landry
wrote:
If I run
db_dump -p memberuid.db
I see entries like this
#\e1\04\00
:caseIgnoreIA5Match:c00001096\00
BD\03\00
:caseIgnoreIA5Match:c00001096\00
\98D\03\00
:caseIgnoreIA5Match:c00001096\00
\a0D\03\00
:caseIgnoreIA5Match:c00001096\00
\b0D\03\00
:caseIgnoreIA5Match:c00001096\00
and also
#\e1\04\00
=C00001096\00
BD\03\00
=C00001096\00
\98D\03\00
=C00001096\00
\a0D\03\00
=C00001096\00
\b0D\03\00
=C00001096\00
which seems to indicate that adding the matching rule to
the index definition
did something.
From:
"William Brown" <william@xxxxxxxxxxxxxxxx>
To: "General discussion list for the 389 Directory
server project." <389-users@xxxxxxxxxxxxxxxxxxxxxxx>
Sent: Thursday, August 9, 2018 6:07:17 PM
Subject: [389-users] Re: Attempting to make memberUID
searches case insensitive
On Thu, 2018-08-09 at 08:23 -0500, Patrick Landry wrote:
> So what is the point of adding the matching rule when
defining the
> index? Is that
> simply so that the index is built with the *capability*
of supporting
> searches using
> that matching rule explicitly?
I think it would be worth trying Ludwig's suggestion so we can
work out
*what's* going on. Perhaps the assumption we are making about
what the
MR does is incorrect, and it's building a supplemental index.
It's good
to check these things to understand the behaviours.
Perhaps something else to do is check to see what content is
in the
memberuid.db file to see what indexes were added.
Finally, did you run db2index again? I don't know if you
answered this.
--
Sincerely,
William
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to
389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx/message/WZZPSVL7QQWQSR43BHTJ6NTPVESYPZ2N/
--
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx/message/TEHKFUHBOUMSFOGNM3N4VJURJSXI7H47/
--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander
|
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx/message/TG2QZWJIKMV3D3QU2YMGXJ2HZ4PWV333/
