directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject General issues with Lookups and Searches
Date Wed, 19 Jan 2011 16:18:21 GMT
Hi,

as usual, trying to fix a bug can leads to many others...

1) Lookup operation usage
first, we have to consider that Lookup has many meanings, depending on 
the context.
- JNDI : the Lookup operation returns a Java object
- LDAP : there is nothing such as a Lookup operation in LDAP, but we 
have one in out API

One more problem is that JNDI has a getAttributes() operation which is 
what our Lookup operation does in our API.

Last, not least, inside the server, a lookup is done when we want to 
fecth an entry with *all* its attributes.

This is just a mess...

Here is what I suggest, feel free to provide your opinions :
- lookup operation will remain in our API, and it will behave the exact 
same way than a search done with a BASE_OBJECT scope, (objectClass=*) 
filter. A user can pass a list of requested attributes, plus the special 
values '+', '*' and '1.1'. The parameter 'TypesOnly' can also be used. 
Controls are accepted
- inside the server, we will rename the operation to fetchEntry(), and 
it will bypass all the interceptors (we will just call 
nexusPartition.fetchEntry( DN )).
- the JNDI layer we provide will map getAttributes to lookup, and the 
JNDI lookup method will still unmarshall the result to a Java instance.

2) Search Operation execution
Right now, the way we process a search is that we create a cursor, add 
some filters to this cursor, and then loop on the cursor, fetching a 
candidate from the backend (which will evaluate the entry against the 
filter), and filtering the enry before it returns it.

So far, so good except that it does not work for a filter done on 
collective attributes (like '(c-l=Paris)' will not match any result). 
This is because in the searchEngine, the entry we are processing does 
not have *yet* the collective attribute added.

One way to fix this would be to remove the collective attributes check 
from the filters, and to filter the entry higher (in a filter added to 
the cursor). Obviously, it will come with a cost, unless we add some 
index for collective attributes.

3) Lookup processing
Depending on the way we do a lookup from outside of the server, we will 
have a different way to process it :
- if we go through the ServerContext.getAttributes() method (JNDI API), 
we directly call the operationManager.
- if we use out API, we first go through the CoreSession instance, which 
calls the OperationManager.

The problem is that we can't filter the attributes if we do a lookup 
through our API, when we can with the JNDI call, because we filter the 
unwanted attributes in serverContext.

My first thought was to modify the ServerContext to call the CoreSession 
which itself calls the OperationManager, and add the filtering of 
Attributes in CoreSession, but sadly, this is not possible because in 
this case, we lose the controls.

Here is what I suggest to fix this situation :
- make the ServerContext call CoreSession
- add the filtering of attributes in CoreSession
- modify the Lookup operation in our API to pass the controls


That's pretty much it with the problems I currently have...

thoughts ?

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


Mime
View raw message