directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <seelm...@apache.org>
Subject Re: [Schema refactoring] Need some extra data structure to manage schema manipulation
Date Wed, 07 Oct 2009 21:10:48 GMT
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

Mime
View raw message