Re: Issue when injecting a new AttributeTypes in OpenLdap

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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.

-- 
Hallvard