On Sat, Sep 26, 2009 at 3:23 PM, Emmanuel Lecharny <elecharny@apache.org> wrote:
Hi guys,

just a question on schema, and theirs state.

When we inject a schema in the server, we store it on disk in a Ldif partition. All the schema objects are then written to disk (id we inject a OpenLDAP format schema or the ldif counterpart). At this time, it's disabled by default, and each schema element has an attributeType m-disabled set to TRUE. The registries does not contain any of the loaded elements, except if the m-disabled AT is set to FALSE (and even then it all depends on if the schema is enabled or not)


If the m-disabled attribute is not present then it defaults to FALSE I think.  So deleting the m-disabled attribute enables the schema as well.
 
In order to be able to use this schema, we have to switch this AT to FALSE (ie, now, it's enabled). That will be reflected on disk as the schemaObject ldif entry will be rewritten. It also has an impact on the registries, as they will now contain the schema's elements.


Yes this change will trigger loading that schema.
 
So the basic rules, AFAIK, are :
- a schema is disabled when loaded, unless it's explicitely enabled

If a schema is loaded it is enabled.  You must mean something else besides "loaded" here.
 
- if a schema is disabled, then all the contained schemaObject are disabled, even if they are marked as enabled

When the schema subsystem was originally devised we did not have schemaObject level enable/disable capabilities.  Actually I did not know we added this until now.  However I think the schema enabled/disabled bit should override individual schemaObject enabled/disabled bit to exhibit the kind of behavior one would intuitively expect.
 
- when we enable a schema, all the contained element not explicitely marked as disabled are loaded into the registries

This is true.
 
- when we disabled a schema, all the associated schemaObjects are removed from the registries

This is true.
 
- we can't disabled a schemaObject if another enabled schema object depends on it (like if the disabled element is an AT and is the superior of another AT)

This is true: the schemaObject depending on the candidate to be disabled must be disabled first.  Eventually we should allow for a cascade disable capability to make this easy and atomic.
 
- whatever we do on the schema does not impact the data, in any way.


This is true.  However it may impact the server so it is no longer able to return entries with modified or deleted schema objects pertinent to the entry being returned.
 
Regards,
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org