directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject AP rename operation reviewed
Date Sat, 08 Jan 2011 17:59:53 GMT

here is a reviewed version of the Rename operation, as I know have a 
better vision of what it implies.

Subentry rename :
Renaming a subentry has *no* impact on the DIt, but we have to update 
the Subentry cache, as we store the CN in the subentry class. To 
retrieve the modified subentry in the SubentryCache, we will use its DN 
as an index. The 4 APCaches won't be impacted.

AP rename :
Here, we have to handle two different cases for each role. We will 
process each role accordingly :
1) the AP is a SAP or an IAP for the processed role
   If the AP is a SAP, we can safely rename it, rename all the 
underlying entries, and we are done. We don't need to update the 
seqNumber because we haven't modified anything that could impact the 
subtree specification for any of the associated subentries. Enough said 
that the subtree specification will only contain LocalName for the base, 
chopBefore and chopAfter elements, all those names being relative to the 
AP's DN.
   If the AP is a IAP, it's a different story. We now have to check if 
the chain of IAP for this role up to the parent SAP for this role have 
subtree Specification that define a base, a chopBefore or chopAfter 
localName, because if they do, then the evaluation will have to be done 

Here, we consider that renaming an AP should *not* impact the 
subtreeSpecifications. It's up to the admin to modify those subtree 
specification accordingly to the renaming being done.

If any subtree have been impacted, then we must update the associated 
AP's seqNumber, in order to have the entries being reevaluated when 
accessed. It's enough to get a new seqNumber and to inject it in the 
modified IAP/SAP. We will do that for each IAP up to the parent SAP.

2) the AP is not a SAP nor an IAP for the processed role
   Then the AP will be considered as a standard entry, and will be 
processed accordingly (see below)

Entry rename :
We fall in the same case as when the AP is renamed, and it's an IAP. We 
have to check the entry's parent AP, for each role, and check if the 
associated subtree specification contain references to the previous 
name. if so, we have to update the AP's seqNumber. If the entry's parent 
AP is an IAP, we must continue until we get the parent SAP.

Note : this is the ultimate solution, but we can also play medieval on 
APs, not checking the subentries. However, that would be brutal, because 
we may impact may entries that are not under the modified entry. This is 
typically a case where we may modify more entries than what we could if 
we were to update the underlying entries immediately.

Emmanuel L├ęcharny

View raw message