OpenLDAP Project wrote:
OpenLDAP 2.4.7 is now available for download as detailed on our download page: http://www.openldap.org/software/download/
and should soon be available on all official mirrors: ftp://ftp.openldap.org/pub/OpenLDAP/MIRRORS
This is a maintenance release and is made available for general use. Users of OpenLDAP Software are encouraged to upgrade.
Significant contributors to this release include: Howard Chu (Symas Corp) Quanah Gibson-Mount (Yahoo! Inc) Ralf Haferkamp (SUSE Linux) Gavin Henry (Suretec Systems) Pierangelo Masarati (Sys-Net)
OpenLDAP 2.4.7 Release (2007/12/14) Added slapd ordered indexing of integer attributes (ITS#5239)
Note that the above caused an incompatible format change in the back-bdb/hdb index databases. If you've used any presence indexing or equality indexing of integer attributes, you'll need to run slapindex to get the new format. slapindex -q -t should do the trick.
Obviously there've been a lot of other changes. There are still one or two new features in CVS that will show up in the next 2.4 release. But in the meantime, this release is generally more usable than 2.3.
On Fri, 14 Dec 2007, Howard Chu wrote:
OpenLDAP 2.4.7 Release (2007/12/14) Added slapd ordered indexing of integer attributes (ITS#5239)
Note that the above caused an incompatible format change in the back-bdb/hdb index databases. If you've used any presence indexing or equality indexing of integer attributes, you'll need to run slapindex to get the new format. slapindex -q -t should do the trick.
As one who forgot this advice, what behaviour can I expect to see? I have an "eq" index on e.g. uidNumber, with no apparent ill-effect.
Dave Horsfall wrote:
On Fri, 14 Dec 2007, Howard Chu wrote:
OpenLDAP 2.4.7 Release (2007/12/14) Added slapd ordered indexing of integer attributes (ITS#5239)
Note that the above caused an incompatible format change in the back-bdb/hdb index databases. If you've used any presence indexing or equality indexing of integer attributes, you'll need to run slapindex to get the new format. slapindex -q -t should do the trick.
As one who forgot this advice, what behaviour can I expect to see? I have an "eq" index on e.g. uidNumber, with no apparent ill-effect.
You probably have too small a database for it to make a visible difference, or nobody is doing equality searches on the uidNumber attribute. If you don't re-index, then you're essentially running the same as no index on your integer attributes. Likewise, all of your presence indices are invalid.
On Wed, 19 Dec 2007, Howard Chu wrote:
As one who forgot this advice, what behaviour can I expect to see? I have an "eq" index on e.g. uidNumber, with no apparent ill-effect.
You probably have too small a database for it to make a visible difference, or nobody is doing equality searches on the uidNumber attribute. If you don't re-index, then you're essentially running the same as no index on your integer attributes. Likewise, all of your presence indices are invalid.
I thought searches were a bit slow... Thanks (yes, it's a small DB).
Howard Chu writes:
Dave Horsfall wrote:
As one who forgot this advice, what behaviour can I expect to see? I have an "eq" index on e.g. uidNumber, with no apparent ill-effect.
You probably have too small a database for it to make a visible difference, or nobody is doing equality searches on the uidNumber attribute. If you don't re-index, then you're essentially running the same as no index on your integer attributes. Likewise, all of your presence indices are invalid.
Strange, I'd have expected this to break: to behave as if the index was present but empty: No preexisting entries get the (old) index value of the eq filter, so all entries would be filtered away. What am I missing?
Hallvard B Furuseth wrote:
Howard Chu writes:
Dave Horsfall wrote:
As one who forgot this advice, what behaviour can I expect to see? I have an "eq" index on e.g. uidNumber, with no apparent ill-effect.
You probably have too small a database for it to make a visible difference, or nobody is doing equality searches on the uidNumber attribute. If you don't re-index, then you're essentially running the same as no index on your integer attributes. Likewise, all of your presence indices are invalid.
Strange, I'd have expected this to break: to behave as if the index was present but empty: No preexisting entries get the (old) index value of the eq filter, so all entries would be filtered away. What am I missing?
Hm, good point. Either way, it's bad.
openldap-software@openldap.org
-
Dave Horsfall -
Hallvard B Furuseth -
Howard Chu