directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Search, list and lookup semantic.
Date Sun, 28 Feb 2010 23:29:29 GMT
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

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.

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.

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 ?

-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.nextury.com



Mime
View raw message