Emmanuel Lécharny writes:
On 4/12/11 11:19 PM, Howard Chu wrote:
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
So far, it seems just as straightforward in either implementation - same information, just arranged (or at least exposed) differently.
The difference is in what you wrote next:
(note that we added a x-schema extension in the schema elements to retrieve the schema they will be stored in).
Which means that the admin only can do half the job with standard schema syntax. With your server too, the admin still needs a non-standard syntax if he wants to finish the job and properly organize his schemas.
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 ?
Howard already answered that:
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.
There are other ways one could specify which internal schema entry/tree to use when that is not specified in the LDAP update operation - e.g. cn=schema,cn=config & children could hold mappings from OID/schema element name to the entry which should receive the update. Not sure if that's any better. I wonder what X.500 servers do.