directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: General issues with Lookups and Searches
Date Wed, 19 Jan 2011 20:27:01 GMT
On Wed, Jan 19, 2011 at 6:18 PM, Emmanuel Lecharny <> wrote:
> 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

I'd specifically say in our 'internal API', the SPI for Partition and

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

I think we blended the two as a vestigial remnant when we were using
JNDI interfaces inside the server.

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

This is what it should be I would say. Should be because as we
discussed on IM, internally the server needs all attributes to be able
to make some decisions in various subsystems often using operational

The same is used by search to return individual entries however search
handles some additional filtering of attributes to be returned based
on search parameters provided.

> 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

This is a complicated decision. I think what we need to do is review
all the places in which lookup is being using and also where used
check to see how the interceptors are being bypassed. From this tally
we'll know how to best tackle this problem.

> - 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.

The JNDI wrapper around DirectoryService is just fine at doing this
already I would figure.

> 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.

Right this is another shortcoming. The search engine is not virtual
attribute aware. There are ways we can work on this but this I would
treat as a whole separate issue all together. It will distract from
the lookup conversation.

> 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.

I think we should leave this alone and try to tackle one problem at a time.

> 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.

I think we've hazy here because we have not defined fine SPI, API
boundaries and clear semantic contract. Really I think doing this at
this point will cause more churn in the code with less clarification.

> 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.

Yes the tradeoffs are not looking good.

> 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 ?

I recommend deferring the issue temporarily and working together to
cleanup these SPI, API interfaces while evaluating what we have
overall in this iterative process.

We can properly document the API/SPI boundaries, and specify the
expected behaviors (semantics) clearly first. Then maybe refactor a
bit to make sure it's all an intuitive picture that we can support
painlessly for a long time to come.

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message