On 4/12/11 11:19 PM, Howard Chu wrote:
Emmanuel Lécharny wrote:
On 4/12/11 8:52 PM, Howard Chu wrote:
Not a piece of cake !
As Hallvard said, OpenLDAP already supports dynamic schema changes, and changes take effect immediately without any restart required. And, as noted, throwing all dynamic changes into a single cn=subschema subentry (or 99user.ldif as some other servers do) is messy. I prefer to keep things well organized, with related schema elements all in their own entry. This makes schema development and management a lot easier and understandable, particularly when you're wondering what schema element came from where.
We do allow modification in both cn=schema (cn=subschema in OpenLDAP) and in ou=schema (cn=schema,cn=config in OpenLDAP) in ApacheDS, and whether you modify one or the other, both are impacted.
Considering that the cn=(sub)schema is just a virtual DiT (ie, it's built on the fly when a user request it), it's should not be a real problem to update it.
What kind of problem can you foresee, Howard ?
Performing an update is not the problem. Funneling updates of cn=subschema into meaningful branches of the schema tree is the problem.
Got it.
We have a workaround for that : each schema is stored in it's own sub-entry, with each schema element in a dedicated sub-entry :
ou=schema cn=core ou=attributeTypes m-oid=2.5.4.4 (sn) ... ou=objectClasses ... cn=system ...
With such a structure, the mapping is straightforward (note that we added a x-schema extension in the schema elements to retrieve the schema they will be stored in). Now, for every newly added schema element, as we can't require this x-schema to be present (otherwise it would not be portable), they will be added to a special schema file, named 'other'.
wdyt ?