[Date Prev][Date Next]
RE: back-bdb slapadd
> -----Original Message-----
> From: Hallvard B Furuseth [mailto:firstname.lastname@example.org]
> 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
> > 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
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support