[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Patch for search -s one/sub -b "" [Was: DSE Root/first entry]
Hi All,
"Kurt D. Zeilenga" 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.
> >>
> 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 == "".
>
Could developers review the attached patch please. The patch is for servers/slapd/back-ldbm/search.c
of openldap HEAD branch cvsupped yesterday. It allows one-level and subtree search with the "" (root)
base. There should be suffix "" in slapd.conf.
>
> 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 did not understand whether Kurt meant OpenLDAProotDSE as a virtual root Entry or simply a fake Entry
*e. As both search cases do not need OpenLDAProotDSE, I decided the second option. There is a static
Entry root_entry structure with its fields set to 0, "" and NULL.
>
> 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
Done. However, if scope is base and DN == "", search does not call any callback anyway.
>
> 1) handcraft e as needed by search_candidates
It is OK to call is_entry_referral, is_entry_alias and search_candidates with the introduced
root_entry.
> 2) call search_canditates
OK.
> 3) set realbase
It is set to "" automatically from root_entry.e_ndn.
> 4) free(e)
Not needed because root_entry is a static structure.
> 5) jump to below cache_return_entry
Logic of this condition is inverted: don't call cache_return_entry for root_entry
>
> The slimit/tlimit code would have to be relocated so as not
> be jumped over.
>
Logic is inverted again: slimit/tlimit are called for any e.
>
> Then it's a matter of ensuring the appropriate DN indices
> have been generated and that the candidate code is correctly
> using them.
>
This magically happens without any further changes :-)
Best regards,
Konstantin.
--
* * Konstantin Chuguev - Application Engineer
* * Francis House, 112 Hills Road
* Cambridge CB2 1PQ, United Kingdom
D A N T E WWW: http://www.dante.net
*** search.c.orig Mon Sep 25 05:49:27 2000
--- search.c Wed Oct 18 16:52:40 2000
***************
*** 23,28 ****
--- 23,30 ----
Backend *be, Entry *e, Filter *filter,
int scope, int deref, int manageDSAit );
+ static const Entry root_entry = { 0L, "", "", NULL, NULL };
+
int
ldbm_back_search(
***************
*** 59,64 ****
--- 61,69 ----
if ( deref & LDAP_DEREF_FINDING ) {
e = deref_dn_r( be, nbase, &err, &matched, &text );
+ } else if ( *nbase == '\0' && scope != LDAP_SCOPE_BASE ) {
+ e = (Entry *)&root_entry;
+
} else {
e = dn2entry_r( be, nbase, &matched );
err = e != NULL ? LDAP_SUCCESS : LDAP_REFERRAL;
***************
*** 144,150 ****
/* need normalized dn below */
realbase = ch_strdup( e->e_ndn );
! cache_return_entry_r( &li->li_cache, e );
if ( candidates == NULL ) {
/* no candidates */
--- 149,157 ----
/* need normalized dn below */
realbase = ch_strdup( e->e_ndn );
! if ( e != &root_entry ) {
! cache_return_entry_r( &li->li_cache, e );
! }
if ( candidates == NULL ) {
/* no candidates */