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/
