[Date Prev][Date Next]
Re: ordered indexing for integers
Agreed that this would be a useful addition (I've run into/designed around
this a couple times). To answer "is it a big deal that we lose binary
compat with RE23," I don't consider that a strong issue at all. We always
tell people to slapcat/slapadd as part of a release change, and this would
be covered in that recommendation. My bigger concern would be what the
2.4.6 -> 2.4.7 (or whenever this hits) procedure would look like. i.e.,
are you proposing dropping read support for the RE23-style databases, so
that a 2.4.6 -> 2.4.7 would require a 2.4.6 slapcat? Users might not be
used to that.
On Tue, 20 Nov 2007, Quanah Gibson-Mount wrote:
--On Tuesday, November 20, 2007 6:57 AM -0800 Howard Chu <firstname.lastname@example.org>
I was looking at adding support for ordered indexing for Integer
attributes. This would be an incompatible format change for index
databases. In fact I'd need to change the Presence index key as well, so
it would affect all index databases, not just those for Integer
Currently the Presence index uses a hardcoded 4 byte key of 0x00000001. I
want to change it to a 2 byte key of 0x0000 instead, to prevent it from
colliding with the Integer key space.
So far, 2.4 and 2.3 have totally identical database formats. Is it
worthwhile to break this compatibility to gain this feature, or better to
preserve compatibility and ignore this feature for now? Any thoughts on
going ahead with it here in RE24?
I think every other release has had incompatible changes, and if we are
contemplating one for 2.4, we need to do it sooner rather than later. Since
2.3.39 was just marked stable, I'm guessing not too many people have migrated
to 2.4.6 so far. We'd definitely want to note highlight this change when
pushing 2.4.7. As for the feature, I think it sounds quite useful, I've
wanted to do ordered integer searches in the past...
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration