back-bdb flaw

[Howard Chu <hyc@symas.com>]

There appears to be a long-standing problem with back-bdb and entries with 
more than BDB_IDL_DB_MAX immediate children. If the entryIDs of the children 
are non-contiguous, then attempts to delete the subtree of the entry will 
fail, because the IDL range for the OneLevel index in the dn2id DB will never 
zero out.

back-hdb doesn't have this problem.

Not sure what an appropriate fix is. Ideally, when deleting an entry whose ID 
corresponds to either the lower or upper bound of the range, we should update 
the range with the ID of the next remaining sibling. But there's no easy way 
to search for that ID, so we just increment/decrement the range by 1. The 
OneLevel index is the only structure that can quickly tell us what the 
siblings are, and it's obviously useless when this situation arises.

The only way to search would be to [inc/dec]rement the ID and retrieve the 
corresponding entry's DN to see if it is a sibling of the deleted entry, and 
loop until a sibling is found or we run into the opposite range boundary. On a 
large DB this will be extremely slow.

Seems like the best fix is to deprecate back-bdb and only use back-hdb from 
now on.
--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/