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
subentries.
- 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 ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
