Re: back-bdb flaw

[Howard Chu <hyc@symas.com>]

Michael Ströder wrote:
> Howard Chu wrote:
> > Seems like the best fix is to deprecate back-bdb and only use back-hdb
> > from now on.
>
> But I vaguely remember that back-hdb has higher memory consumption.

Eh? back-hdb has a smaller memory footprint, as well as a smaller on-disk 
footprint.

Maybe you're thinking of the original design in 2.1
http://www.openldap.org/lists/openldap-devel/200303/msg00055.html

which changed quite a bit since then.

Thinking about it some more, we can still salvage back-bdb, but it will 
require a change in the dn2id index format. The only thing that bothers me 
about this is that once you start down the path of making "sensible" changes 
to back-bdb's dn2id format, you eventually arrive at back-hdb anyway, so 
again, is it really worth the effort...

Anyway, the solution I'm thinking of is to reverse the RDN order in the dn2id 
index keys. (I.e., use X.500 order.) This way we can use BDB range lookups to 
find children/siblings of entries. That will give us a quick method of 
validating the OneLevel index. (The next logical step is of course to 
eliminate the OneLevel index because it's superfluous once you organize the 
RDNs this way. But we can stop short of that, no point in repeating the 
development of back-hdb yet again.)

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/