Hallvard B Furuseth wrote:
Howard Chu writes:
> Hallvard B Furuseth wrote:
>> Is the problem only to (make it feasible to) detect this situation, or
>> also to act on it? To detect it, I assume Delete before returning
>> notAllowedOnNonLeaf could search with scope onelevel/children, and see
>> if it finds any entires.
> Yes... back-bdb would also need to check this for modrdn as well. Seems
> like quite a lot of extra expense to perform this check each time.
Only at failure.
We need to do this check whenever deleting an entry whose parent's onelevel
index is an IDL range.
Maybe it's more work than I imagine - it's an index after
Yes, it's an index. But there's no efficient way to determine this info
without the index. (Which again is why back-hdb doesn't do things this way...)
The checks we're considering here could also seriously impair concurrency,
since the Delete transaction could end up taking read locks on many entries
before finding the next sibling.
But IIRC we already have similar slowdowns in situations I'd
assume are more common. When deleting multiple attribute values in an
entry have the same hash, or something.
No, not a comparable situation. In that case, we compute all of the hashes in
memory but we cancel out the duplicates and only push the true changes into
the DB. Computing the hashes is cheap, DB operations are not.
Seems like it's time to revisit this thread...
The notion of bit-vectors for IDLs is looking good again. The whole reason
this problem exists is because range IDLs lose so much information.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/