directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <>
Subject Re: Search, list and lookup semantic.
Date Mon, 01 Mar 2010 08:39:38 GMT
Emmanuel Lecharny wrote:
> Hi guys,
> as I'm trying to remove the JNDI SearchControls from our server, I found 
> three different methods that do a search in the server :
> - search
> - lookup
> - list

Those methods exists with different signatures in multiple parts of the 
- Partition interface
- Interceptor interface
- CoreSession interface

I guess the lookup and list methods exists to optimize read operations 
from the partition. And it seems they are mainly used within the server 
for bootstrap and maintenance tasks.

> All those three operations semantic is not exactly clear to me. Let's 
> try to see if they are all useful, and what the semantic is or should be 
> for each of those operations.
> 1) lookup : The javadoc says : "Looks up an entry in the server 
> returning all attributes: both user and operational attributes.". In 
> fact, we can define the list of Attributes to return. What is not clear 
> is that we don't know if the lookup is done with a ONE_LEVEL scope, or a 
> SUBTREE scope. There is also a difference with JNDI lookup operation 
> that returns a Java instance.
> IMO, we should drop the JNDI semantic completely (the returned value 
> should be an Entry, not a Java instance), and the scope should be SUBTREE.

Hm, all the lookup methods I see already return an "ClonedServerEntry". 
I think the lookup method is very useful, we should keep it.

> This resolve to a search with ALIAS_DEREF_ALWAYS, scope SUBTREE, filter 
> (ObjectClass=*), size and time limit set to infinite, no controls, 
> typesOnly set to false.

The lookup method just returns the requested entry, so OBJECT scope.

> 2) list : The javadoc says : "An optimized search operation using one 
> level search scope which applies size and time limit constraints and 
> returns all the children of an entry specified by distinguished name if 
> these limits are not violated"
> This is easily replaced by a plain search. I think we can get rid of 
> these methods, which are anyway used only in two places.


> 3) search : the base method for all the searches. We have a few 
> overloaded methods for search :
> - search( SearchRequest ) : The base method. Takes all the needed 
> information directly from a request.
> - search( DN, Filter ) : This is a common one. The question is to 
> determinate which are the dfault values for the scope and alias deref 
> parameters. I suggest SUBTREE and DEREF_ALWAYS. Time and size limits are 
> set to infinite (0), we don't have any controls, and no returning types. 
> All the values are returned.
> - search( DN, filter, scope ) : same, but the scope is defined.
> - search( DN, filter, scope, String... attributes ) : The last one with 
> many parameters. In this case, we list all of attributes to return.
> - search( DN, filter, SearchParams ): In this case, we use another 
> object to store all the parameters we want to use less frequently : time 
> limit, size limit, types only, Alias deref, and controls.
> I think we should be able to manage all what we want with those operations.
> wdyt ?

Maybe we can converge the search methods of the server and the client API?

Kind Regards,

View raw message