RE: back-bdb slapadd

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no]

> Howard Chu writes:
> > It is potentially slower now, since it does a dn2id lookup
> on each DN, before
> > assigning an ID to a new entry. I suspect this difference
> is trivial, but it
> > bears mentioning.
>
> Would it be faster to try to add the entry the old way, and only use
> your way if the add fails due to a missing parent?

The old code doesn't detect this condition. It will, however, fail to add the
parent later on, because the parent's subtree index slot has already been
created.
>
> > For an unsorted file, there is the potential to leave "holes" in the
> > database - it may create a parent node in the dn2id index,
> but the LDIF input
> > might not supply the actual parent entry. There is no
> detection of this
> > condition,
>
> The database could remember the IDs/DNs of such holes from they are
> added that way and until they are "filled" properly.  Slapadd
> could fail if any holes are left when done.

Yes, I was thinking along these lines.

> > and a subsequent attempt to ldapadd the missing parent would fail
> > with "DN already exists" or somesuch.
>
> Does any code in back-bdb assume that if an ID exists, the
> entry exists?

I'm not sure what you mean by this. Since the dn2id index is populated, a
search's subtree candidates would include those IDs. Currently the search
loop will just ignore any missing entries, so I guess that's harmless. For a
lot of other functions, where a specific entry is required, it would cause
problems.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support