directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Subentries handling refactoring
Date Thu, 15 Jul 2010 17:33:41 GMT
  Hi guys,

we have serious issues with the way we manage subentries in the server. 
Not that it's not working, but it's certainly not good enough for 
anything but a toy server.

Let me first give some heads up about what's going on.

A subentry is associated with an AdministrativePoint (AP), and defines a 
selection of entries which will be affected depending on the AP role. 
Those roles are :
- Access Control
- Collective Attributes
- SubSchema (not active atm)
- Triggers (ADS specific).

For instance, if we have a tree with a set of entries associated with a 
location (ie, c=France), we may define a subentry with a Collective 
Attribute role telling the server that every entry under the c=France 
branch will have a specific attribute added. We don't have then to add 
this attribute to *every* entry in this branch...


A subentry defines a selection using a filter, and a base DN for this 
filter to be active from.

Right now, a Subentry is attached to an AP as a (quite) normal entry, 
and when we add this subentry, we modidy *all* the selected entries 
(using the subentry filter and the base DN) will be modified to have a 
new attribute added. This added attribute contains a DN poiting to the 
associated subentry, so that when we process this entry, we can 
immediately know that it's associated with an AP.

So far, so good : processing an entry is fast, as we have all what we 
need when we have the entry. But the dark side is that if we have 
millions of entries, when we add an AP and a subentry, we may have to 
modify potentially *millions* of entries to add this attribute. Not good...

How can we improve this process ?

The idea would be to search for the APs when we process an entry, but it 
has to be fast. How can we do that ? Simple : we use the entry's DN and 
using a DN cache, we can get all the APs associated with an entry 
knowing its DN. It's as costly as the depth of the entry's DN. Once we 
have grabbed the APs, we will have to evaluate the entry to know if it's 
part of the selections defined by the APs' subentry. Done.

Is it costly ? Only marginaly compared to the current algorithm, as we 
have to lookup for the AP, when we have this list in an Attribute in the 
current server. But we spare the big modifications when adding - or 
removing/renaming/moving - a subentry.

What we just need is a APs cache and a way to process it.

This is what I will work on in the next few days if nobody objects or 
find a better algorithm.

Emmanuel L├ęcharny

View raw message