On Fri, Jan 14, 2011 at 10:03 AM, Emmanuel Lecharny <[email protected]> wrote: > Hi, > > yesterday, as I was tracking an issue with the ChangeLog interceptor > position in the chain, I found that if we modify some schema element in > ou=schema, we just update the SchemaManager, but the modification is not > stored on disk in ou=schema. >
CN=schema as opposed to OU=schema is a virtual entry which does not really exist on disk itself. Operations against the CN... are translated into operations on the OU... area. This is because the LDAP schema subentry is a poor mechanism for storing large amounts of information, schema information, in a textual format instead of a parameterized format that is easier to use to maintain schema consistency. To be more specific, the protocol defines a syntax for schema elements which are presented via the schema subentry as values of attributes like attributeTypes. The value being one big string. This string form is not very efficient for maintaining consistency since you would have to parse these strings every time while determining whether or not a schema change impacts these elements due to a dependency. It would become an intractable problem. So this is why when I redesigned the schema subsystem way back I created our own format under the OU... area that was more conducive as an internal representation. When operations against the CN... schemaSubentry are performed as expected in the LDAP protocol as the standard mechanism, these operations are translated into changes against the OU... area where parameterized representations of these schema entities are managed on inside the schema partition. > I think this is an error, but may be there is some rational in this > behavior. > See above. > Do you guys confirm that any modification made on ou=schema must be > reflected by a modification in cn=schema ? Absolutely! You already know this I'm sure, we probably talked about this several times while you were revamping the schema interceptor. Maybe you temporarily forgot it because of the AP nightmare's strain. > FTR : ou=schema represents the in memory schema, normally instanciated at > init time after reading the on disk schema stored in cn=schema. You probably flipped this while typing. But neither is in memory. At the end of the day what you have are the registries in memory with the Java schema model used to model these schema entities. This model is presented via the CN... facade as the LDAP protocol specifies it. The OU... area is an internal on disk persistent representation used to load the registries, which is the in memory representation. When you read the CN... area it shows you what's in the registries (what's been loaded from OU... the persistent area). It contains > only the active schema elements, not the disabled part of the disk schema. Yes the CN... will only show you the active schema elements. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
