Andrey Ivanov wrote:
2010/8/25 Rich Megginson <rmeggins(a)redhat.com
<mailto:rmeggins@redhat.com>>
Andrey Ivanov wrote:
Hi,
I am testing the 389 latest git version. There is one
thing i have
noticed concerning Outlook browsing of LDAP and VLV indexes.
Though i
think the change has happened already some time ago, in
one of the
previous versions.
Can you confirm the last version that this worked in? I suspect
this had something to do with my matching rule changes in 1.2.6.
The goal is that it should work the same way as before, so this
is definitely a bug.
No. It is not a bug, it was my mistake. I've just tested several
versions of 389 and FDS (1.2.x, 1.1.x and 1.0.4). They all exhibit the
same behavior concerning the sorting of CNs in VLV browsing.
So then i still have this second question - is there a way to change
the vlv index sort in order to sort according to nsMatchingRule? Or it
would be a feature request?
*) i've tried to add collation rules to vlv index entries but
putting the value of the attribute
vlvSort to "cn:2.16.840.1.113730.3.3.2.18.1.6" or to
"cn:fr". It does not work. Instead of changing the sorting order
it produces some strange contents in the index
vlv#outlookbrowseindex.db4 file.
**) then i thought that maybe i should change the cn index ordering
and i have added "nsMatchingRule: 2.16.840.1.113730.3.3.2.18.1" to the
cn indexes in dse.ldif. However reindexing does not actually
change the order in cn.db4 (even after reindexing by smth explicit
like db2index -n userRoot -t
cn:eq,pres,sub:2.16.840.1.113730.3.3.2.18.1 ) in the index .db4 files.
I did see
some code in the vlv code to handle i18n matching rules, and
there is indexing code for i18n matching rules. Not sure what's going
on here - haven't had a chance to look into it.