directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <>
Subject Convo about collective attributes
Date Fri, 21 Sep 2007 14:43:39 GMT
Hi guys,

we have had an interesting convo yesturday (debug session) wuth Alex.
Here is what we talked about.

While debugging the collective attribute (CA) interceptor, I faced a
strange error. When processing a search, the way CA are handled is the
following :
1) do a lookup for the entry
2) filter the result and add the CA if the returned entry contains a
collectiveAttributeSubentries (CAS) attribute
  3-1) return the entry augmented with the CA if the CAS is found
  3-2) or just return the entry as is.

This is ok, but the step (2) did another lookup in the backend, so
there was 2 lookups for one single entry (overkilling ...). So I
removed this ssecond lookup, as we already have got the entry

Everything went right in standard searches, but when you specify some
returned attributes, like a CA, to be returned, then the entry comes
back without anything ... Puzzling !

After some debugging, I found that the search does a lookup, and in
the partition, the lookup semantics is : get all the attributes for
the specified entry, unless you specify some attributes, then simply
return the found attributes. Of course, as CA are _not_ stored within
the entry, if you ask for this CA only, you won't get it. And as the
lookup returns only the requested attributes, it does not return the
CAS anymore. So the collectiveAttribute won't find this CAS, and won't
add the CA value... This is a dead end, and now I understand why there
is a second lookup : to workaround this problem. The second lookup is
done without any requested attribute, so you get the whole entry, and
then you can find the CAS, and add the CA.

How to fix this bad workaround ? There is a solution :
- modify the lookup semantic to avoid dealing with requested attributes

Sadly, doing that has such extensive implication that it's not
possible to do that in the current version (1.5). So this is not an
easy solution.

There is another way to fix the problem, which is a hack, but this
hack avoid a double lookup when the user don't specify an attribute
(this hack is not really interesting...)

Up to this point, we were discussing about how to fix this problem,
but then we switched to the reason why we have this semantic for the
lookup method. Alex pointed out that the fixes mad in the filter
handling this week also modified the Partition semantic. Here are the
important points :

1) Lookup should have another semantic : it simply should returns
entries, with all its attributes.
2) The LeafEvaluator which has been modified in the Parttion is really
specific to the BTree implementation. If we have to change the
backend, then the server won't work anymore, unless a new
LeafEvaluator class is written (and it's not really the easiest part
!). The idea is to get this evalutaion done _before_ the backend. For
that, we need to modify the lookup method and split it in three
methods :
 - lookupWithDN( DN ) which will return a single entry, the one
associated with the DN (or null if there is no entry)
 - lookupWithAttribute( attrId ) which will return an enumeration of
entries, using the indexed attribute. This lookup should only be used
if the attribute is indexed.
 - lookupAll() will return all the entries. It's a full scan.
Then you can build the evaluator on top of the Partition, and decouple
its logic from the backend implementation.
Another advantage will be that we will be able to build an entry cache
 on top of the backend, as we will simply have to implement it as a
Partition. The 3 lookup methods will be mapped to return an object if
it is cached, otherwise ask the real partition for the object.

This is what we discussed yesturday, if anyone want to comment this
mail, you are welcomed. Alex, feel free to comment it if you feel that
I have missed something

Emmanuel L├ęcharny

View raw message