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.