>> 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.
Absolutely. >> 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. Most certainly. This is how I wil implement the function then. >> - 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. Probably a good idea (cascading). But a first step is to forbid it right now. >> >> - 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. Except if you use a filter using one of those deleted attributes, the server should still be able to return the entries. To be checked. Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
