[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: DSE Root/first entry



At 02:05 PM 10/16/00 +0100, Konstantin Chuguev wrote:
>... the thread moved from openldap-software to openldap-devel...
>"Kurt D. Zeilenga" wrote:
>> At 10:29 AM 10/13/00 +0100, Konstantin Chuguev wrote:
>> >You say that with OpenLDAP we should be able to manage suffix "" and first level entries, only
>> >a bug prevents it. I would like to help to find the bug. Can I know the details please.
>>
>> Basically, one needs to special case a base DN "" search
>> such that it the search "locates" the base.  Then likely
>> the DN index subsystem would need to be adjusted.
>>
>> There are some changes in HEAD which might help... they
>> need to be tested and any other issues raised, discussed,
>> and resolved.
>>
>
>Sorry for being too curious :-)
>Can anybody give me more details on what exactly is the problem?

As I noted above, the backend search won't be able to locate
an entry at the root as there is no entry at the root.  Basically,
the special case needs to be added to handle e == NULL and
nbase == "".

There are two ways to handle the special case.
        a) set e to a virtual root Entry
        b) leave e == NULL and special case codes
        to treat e == NULL as a search upon "".

I suggest a).  Basically, inside of e == NULL conditional I would
add if( nbase is empty ) condition which would:
        0) verify scope is not base
        1) handcraft e as needed by search_candidates
        2) call search_canditates
        3) set realbase
        4) free(e)
        5) jump to below cache_return_entry

The slimit/tlimit code would have to be relocated so as not
be jumped over.

Then it's a matter of ensuring the appropriate DN indices
have been generated and that the candidate code is correctly
using them.


>Can it be that this code (i was looking at 2.0.4) is those changes in HEAD Kurt was talking about?

I made changes so that one could add/delete top-level entries.
These changes are in HEAD and, IIRC, 2.0.6.

Kurt