summaryrefslogtreecommitdiffstats
path: root/ldap/servers/slapd/back-ldbm/proto-back-ldbm.h
diff options
context:
space:
mode:
authorRich Megginson <rmeggins@redhat.com>2007-10-02 18:39:51 +0000
committerRich Megginson <rmeggins@redhat.com>2007-10-02 18:39:51 +0000
commit25cb11892e6582a11bb81efa850ae220906471d7 (patch)
treec4cdd1efcf96f6614aeccc798032a30b370a9e6a /ldap/servers/slapd/back-ldbm/proto-back-ldbm.h
parent07ac2ad57c85a4db8ec6fbf5f894f11e377550af (diff)
downloadds-25cb11892e6582a11bb81efa850ae220906471d7.tar.gz
ds-25cb11892e6582a11bb81efa850ae220906471d7.tar.xz
ds-25cb11892e6582a11bb81efa850ae220906471d7.zip
Resolves: bug 249366
Bug Description: rhds71 - search filters returns too many entries on integer attributes value greater than 2 to the power of 31 Reviewed by: nkinder, nhosoi (Thanks!) Fix Description: The way >= and <= searches are supposed to work in LDAP is that you are supposed to define an ORDERING matching rule for the attribute you want to use in the search filter. The way our code is written, most strings "just work" as a side effect of the way bdb sorts the keys by default - so you can do (uid>=jvedder) and get what you would expect, even though LDAP says this is illegal because the schema definition of the uid attribute does not have an ORDERING matching rule. And INTEGER worked with the old binary format for the same reason. The only attribute definitions we use with ORDERING are attributes that use Generalized Time syntax (e.g. createTimestamp, et. al.) and numSubordinates (which uses INTEGER, but this is a special case handled internally by the db code). The way it works now is that the indexing code will honor the ORDERING matching rule specified in the schema definition. Or, if ORDERING is not specified, the user can use the nsMatchingRule index configuration. This will allow an existing customer that depends all integer syntax attributes (e.g. uidNumber) to allow range searches by default to enable range searches without editing the schema. The syntax definition for the attribute must also specify a compare function. This compare function will be used by the bdb bt_compare() function. I also fixed a bug in the integer normalize code - a string of all zeros should normalize to a single "0". In all other cases, the leading zeros should be removed. Platforms tested: RHEL5 x86_64 Flag Day: Yes. Integer indexes will need to be rebuilt (except for numsubordinates). Doc impact: Yes - document slapi API additions QA impact: Pay close attention to tests that use >= or <= search filters, both with and without index attributes. Also, pay close attention to greater/less than searches using i18n collations. New Tests integrated into TET: Forthcoming
Diffstat (limited to 'ldap/servers/slapd/back-ldbm/proto-back-ldbm.h')
-rw-r--r--ldap/servers/slapd/back-ldbm/proto-back-ldbm.h2
1 files changed, 1 insertions, 1 deletions
diff --git a/ldap/servers/slapd/back-ldbm/proto-back-ldbm.h b/ldap/servers/slapd/back-ldbm/proto-back-ldbm.h
index c3ef2ff0..34c76d50 100644
--- a/ldap/servers/slapd/back-ldbm/proto-back-ldbm.h
+++ b/ldap/servers/slapd/back-ldbm/proto-back-ldbm.h
@@ -141,7 +141,7 @@ int dblayer_delete_database(struct ldbminfo *li);
int dblayer_database_size(struct ldbminfo *li, unsigned int *size);
int dblayer_terminate(struct ldbminfo *li);
int dblayer_close_indexes(backend *be);
-int dblayer_open_file(backend *be, char* indexname, int create, int index_flags, DB **ppDB);
+int dblayer_open_file(backend *be, char* indexname, int create, struct attrinfo *ai, DB **ppDB);
int dblayer_close_file(DB *db);
void dblayer_sys_pages(size_t *pagesize, size_t *pages, size_t *procpages, size_t *availpages);
int dblayer_is_cachesize_sane(size_t *cachesize);