[Schema refactoring] Need some extra data structure to manage schema manipulation

[Emmanuel Lecharny <el...@apache.org>]

Hi,

<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 :

AT:
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
www.iktek.com
directory.apache.org

Re: [Schema refactoring] Need some extra data structure to manage schema manipulation

[Emmanuel Lecharny <el...@apache.org>]

Stefan Seelmann wrote:
> Emmanuel Lecharny wrote:
>   
>> 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).
>>     
>
> So with the second solution all SO are in one map? So if you need to
> know which OCs using this AT you have to loop over all map items and
> check if they are OC.
>   
Sorry, I mean, we need two tables :
o one for holding the list of SO a SO is using
o one for holding the list of SO using a SO
> I'd vote for the first solution. I think that would be more reusable and
> more object oriented. For example in Studio for the Schema _Browser_,
> currently there is a totally inefficient SchemaUtils class [1] with
> helper methods that loop over all SO to find references. It would be
> cool if we could reuse this in Studio.
>   
Well, with those 2 tables, you will have way better performances than 
wit the current methods of SchemaUtils !

>> 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...
>>     
>
> One risk I see are memory leaks, if SO are removed from the registries
> but still referenced from other SOs.
>   
Yes, but this is a theorical risk, as we are so damn good coders !!!

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: [Schema refactoring] Need some extra data structure to manage schema manipulation

[Stefan Seelmann <se...@apache.org>]

Emmanuel Lecharny wrote:
> 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).

So with the second solution all SO are in one map? So if you need to
know which OCs using this AT you have to loop over all map items and
check if they are OC.

I'd vote for the first solution. I think that would be more reusable and
more object oriented. For example in Studio for the Schema _Browser_,
currently there is a totally inefficient SchemaUtils class [1] with
helper methods that loop over all SO to find references. It would be
cool if we could reuse this in Studio.

> 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...

One risk I see are memory leaks, if SO are removed from the registries
but still referenced from other SOs.

Kind Regards,
Stefan

[1]
https://svn.eu.apache.org/repos/asf/directory/studio/trunk/ldapbrowser-core/src/main/java/org/apache/directory/studio/ldapbrowser/core/model/schema/SchemaUtils.java