[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Updating a private schema (cn=config)?



Andrzej Jan Taramina wrote:
Howard:

What are you talking about? A schema entry under cn=config has individual
attribute values per schema element.

There is one attribute per schema element, that is, each objectClass or attribute defined in a schema is expressed by a single olcAttributeTypes or olcObjectClasses attribute, which contains a long, complex string which effectively defines other "attributes" of the schema object.

Would have been nicer if the hierarchy looked like this instead:

cn=config
    cn=schema
      cn={4}myshema
        cn={1}myattribute1
	objectClass: olcAttributeTypes
	oid: 1.3.6.1.4...
	name: myAttr1
	desc: This is a sample schema attribute
	equality: caseIgnoreMatch
	syntax: 1.3.6.1.4...
        cn={2}myattribute2
	objectClass: olcAttributeTypes
	oid: 1.3.6.1.4...
	name: myAttr2
	desc: This is a sample schema attribute 2
	equality: caseIgnoreMatch
	syntax: 1.3.6.1.4...
        cn={3}myclass
	objectClass: olcObjectClass
	name: myAttr2
	sup: top
	type: auxiliary
	must: cn={1}myattribute1 $ cn={2}myattribute2

rather than embedding all the attributes of a schema object in a monolithic string.

Then I would have agreed with you, Howard, that it would be easier to edit individual elements.

What you've described is similar to the original design, 3 years ago, but it proved unworkable. You can read through the openldap-devel archives from that time period for more background on the decisions. As I recall, we ran into trouble with schema extensions and a few other elements that didn't lend themselves well to being treated as distinct attributes.


You should learn a bit more about why and how things work, before suggesting they be changed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/