directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject [Schema refactoring] Need some extra data structure to manage schema manipulation
Date Wed, 07 Oct 2009 20:43:33 GMT

<side note>
In the following mails, and all the mails related to the schema, I will 
use those acronyms :
AT : AttributeType
C : Comparator (LdapCOnparator in this case)
DCR : DitContentRule
DSR : DitStructureRule
MR : MatchingRule
MRU : MatchingRuleUse
N : Normalizer
NF : NameForm
OC : ObjectClass
S : Syntax (or LdapSyntax)
SC : SyntaxChecker
SO : SchemaObject (one of the 11 previous elements)

today, while fixing some code, and testing all the atomic operation (Add 
is ok, I started to look at Del), I faced an issue : if we try to remove 
an AT, we may let the Registries in an inconsistent state, as many OC 
may have referenced this AT.

We started to discuss about this problem, and it appeared that many 
different kind of relations exist between each SO. For instance :

o has a S (can be inherited)
o may have some superior AT
o have some MR (can be inherited)
o may be referenced by OCs in theirs MAY or MUST fields
o may be referenced by DCRs in theirs MAY, MUST or NOT fields,
o may be referenced in the MRU's APPLIES field
o may be referenced by NFs in theirs MAY or MUST fields,

If we simply delete this AT without any check, then we may have some 
descendant AT pointing to an AT which is not any more part of the 
schema, or any of the OCs, DCRs, MRUs or NFs referencing this AT.

We have to be able to check that quickly (ie, without visiting all those 
SO looking for this AT), that mean either adding some added fields in 
all those SO (something like the list of OCs using this AT, added as a 
set in the AT instance), or having a Map associating an SO with all the 
SO's referencing it.

I think that the second solution is way better, as it does not add many 
fields and setters/getters in a bunch of classes, and also is easy to 
attach to the Registries. We just have to define a hashCode() for each 
SO which is built using their OID (or ruleId) combined with their 
ObjectType (to avoid collision, as some SO may have the same OID : MRUs 
have the MR's ODI they are associated with).

At this point, the only risk I forsee is that this Map is not accessible 
if the Registries is not accessible when we want to update it. Will see...

Thoughts ?

cordialement, regards,
Emmanuel L├ęcharny

View raw message