When creating/updating an index this is possible to specify the matching rule (nsMatchingRule).
With some matching rule, this configuration fails:
from DSE modify: line 0: unknown or invalid matching rule "caseExactIA5Match" in index configuration (ignored)
The index configuration entry contains the specified MR value, but it is no taken into account during indexing:
dn: cn=givenName,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: nsIndex cn: givenName nsSystemIndex: false nsIndexType: pres nsIndexType: eq nsIndexType: sub nsMatchingRule: caseExactIA5Match
attachment ticket48270_test.py
Replying to [ticket:48270 tbordaz]:
When creating/updating an index this is possible to specify the matching rule (nsMatchingRule). With some matching rule, this configuration fails:
Does this mean that some matching rules work, and some do not? For the ones that do not work, are they incompatible with the syntax of the attribute? For example, givenName is directoryString, which is incompatible with IA5.
Replying to [comment:1 rmeggins]:
Replying to [ticket:48270 tbordaz]: When creating/updating an index this is possible to specify the matching rule (nsMatchingRule). With some matching rule, this configuration fails: Does this mean that some matching rules work, and some do not? For the ones that do not work, are they incompatible with the syntax of the attribute? For example, givenName is directoryString, which is incompatible with IA5.
Ho !! so my test was invalid thanks Rich for catching that. A IA5 matching rules can not be used to compare a directoryString value. I will rework it, to see if I can reproduce: IA5 syntax with IA5 matching rule.
On 10/20/2015 12:48 AM, thierry bordaz wrote:
This is not looking as a trivial bug and needs some evaluation of the amount of work to do.
Freeipa needs this for supporting Kerberos principal aliases that is targeted for freeipa 4.4
attachment 0001-Ticket-48270-fail-to-index-an-attribute-with-a-speci.patch
Looks good!
Thanks for the review !!
Counting objects: 11, done. Delta compression using up to 4 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 1.28 KiB, done. Total 6 (delta 4), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 0cf249e..3752886 master -> master
commit 3752886 Author: Thierry Bordaz tbordaz@redhat.com Date: Fri Feb 5 15:10:42 2016 +0100
Oppss forgot the test case
Counting objects: 8, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 2.56 KiB, done. Total 5 (delta 3), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 3752886..e033d4b master -> master
commit e033d4b Author: Thierry Bordaz tbordaz@redhat.com Date: Mon Feb 8 15:04:33 2016 +0100
This bug also existed in 1.3.4. But it was fixed in that branch by the backport of https://fedorahosted.org/389/ticket/48746 in 1.3.4 (see https://fedorahosted.org/389/changeset/cba64d1ebff2ac68f2bf0d0d858335ef2517aef5/)
So 48270 is not fixed in 1.3.4
Metadata Update from @nhosoi: - Issue assigned to tbordaz - Issue set to the milestone: 1.3.5.0
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1601
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.