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
server:
- 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.
+1
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,
Stefan
