Description of problem: When an index has a configuration parameter: "nsMatchingRule: integerOrderingMatch", the index is sorted by the numeric order instead of the alphabetical order. It's not implemented in the dbverify.
Created attachment 323854 [details] cvs diff back-ldbm/{proto-back-ldbm.h, dblayer.c, dbverify.c} Change Description: 1) changed dblayer_bt_compare to public (proto-back-ldbm.h, dblayer.c) 2) set dblayer_bt_compare by dbp->set_bt_compare if the attribute has a comparison function set in ai->ai_key_cmp_fn (dbverify.c) 3) cleaned up the function dbverify_ext; set the right page size based upon the idl type (new idl or old idl), also set dup compare function only when the idl type is new. (dbverify.c)
Created attachment 323855 [details] sample ldif file Test case: 1. create an equality, integer-ordered index on uidNumber. dn: cn=uidNumber, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=conf ig objectClass: top objectClass: nsIndex cn: uidNumber nsSystemIndex: false nsIndexType: eq nsMatchingRule: integerOrderingMatch 2. import the attached ldif file 3. run verify-db.pl. The result should be "Good". # ./verify-db.pl ***************************************************************** verify-db: This tool should only be run if recovery start fails and the server is down. If you run this tool while the server is running, you may get false reports of corrupted files or other false errors. ***************************************************************** Verify log files in /var/lib/dirsrv/slapd-kiki2/db ... Good Verify db files ... Good
Created attachment 323993 [details] cvs commit message Reviewed by Nathan (Thank you!!) Checked in into CVS HEAD.
fix verified DS 8.1 RHEL 4 created index imported attached ldif bash-3.00# ./dbverify DB verify: Passed -bash-3.00# ./dbverify -n userRoot DB verify: Passed -bash-3.00# ./dbverify -n NetscapeRoot DB verify: Passed
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html