[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 */