directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Update about subtree problems
Date Tue, 20 Jul 2010 15:11:16 GMT
  Ok, let's think more in details about the last idea (using entryUUID 
instead of DN to refer to subentries). We may also need an index to map 
<subentry entryUUID, entry> (<SU, E> so that we can quickly find the 
impacted entries if we modify a subentry. We may need two caches :
- one for subentries : <entryUUID, subentry>
- one for APs : <DN, subentries>

The first cache is used when we need to quickly get a subentry
The second cache is used when we move an entry, to know if it move from 
one AP to another one.

Add operation :
1) we are adding a normal entry
  if it's under some APs, we evaluate it against all the associated 
subentries, and when it evaluates to true, we store the subentries 
entryUUID in the entry. We also update the <SU,E> index.
2) we are adding a subentry
  for each entries under the associated AP, see if they are part of the 
SS, and if so, inject the subentryUUID into the entry. Update the <SU, 
E> index.

Delete operation :
1) we delete a normal entry
  nothing special to do
2) we delete a subentry
  we have to modify all the referencing entries and remove the subentry 
UUID from them. We use the <SU,E> index to get this list of entries. 
Then we can delete the subentry and update the <SU,E> index. One slight 
problem though : we should not be able to process any other modification 
on a subentry while it's being deleted.

Rename operation :
1) We rename a normal entry
  this entry may have children, and some of those children may be AP or 
subentries. However, as we are using entryUUID to reference a subentry, 
this operation has no impact on the entries content.
2) We rename a subentry
  assuming that the subentry will remain in the same AP, we will just 
have to update the caches. Nothing else is needed.

Move operation
1) We move a normal entry
  this entry might have APs in some of its children. They won't be 
impacted. However, as we may move the subtree  from  one AP area to 
another one, we will have to check two things :
   - first we have to list all the subentries the moved entries are 
referring to (we use the AP and subentry cache for that). this can be 
done once for the moved entry, as all the children will share the same 
   - second, we have to find the new subentries the children will depend 
upon once moved.
  Now, we can remove the subentry references from the first set not 
present in the second in each selected entry (using the <SU,E> index), 
add the new subentry references into the selected entries (and we have 
to evaluate all the entries one by one), updating the <SU,E> index at 
the same time, and last, delete all the references from the old 
subentries, updating the <SU,E> index.
2) We move a subentry
   Moving the subentry is a simpler operation : we update all the 
entries containg a reference to the moved subentry (using the <SU,E> 
index to find them), and add a new reference to the moved subentry into 
all the selected entries. It's a delete and add operation, in fact, 
applied to the subentry.
3) We move an AP
   Moving an AP is like moving a normal entry : if we have APs higher in 
the tree (ie closer to the rootDSE than the moved AP), and if we don't 
inherit from the same AP, we then have to udpate the children entries by 
removing the reference to the old subentries and add references to the 
new subentries.

Last operation, not the simplest
Modify operation
1) We modify a normal entry
  No impact if we don't try to modify the references to the subentries 
(something only an admin can do...)
2) We modify a normal entry to make it a subentry
  It's like a subentry creation.
3) We modify a subentry
  Depending on what we modify in the subentry, the consequences will be 
different :
   - if we modify the cn, it has no impact
   - if we modify the OC, for instance by removing the "subentry' 
element, then it's a deletion operation. Anything else has no impact
   - if we modify the subtreeSpecifiction, we can consider that it's 
like a deletion followed by an addition, as we have to reevaluate and 
update all the selected entries
4) We modify a subentry to make it a normal entry
  It's a deletion operation (see case (3), second modification
5) We modify an AP to make it a normal entry
  It should be forbidden if the AP has some attached subentries, 
otherwise it has no impact.

One more thing : how do we deal with aliases ?

Emmanuel L├ęcharny

View raw message