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.
Editing individual schema elements is far more useful than deleting the entire schema and reloading it.
I find it a PITfA, since you have to respecify the whole schema object definition string each time...you can't just change the SUP or the description alone with the current structure, and searches are a pain too. But that is just IMO. When developing a schema iteratively, I find it's easier to have replace the whole thing when you make significant changes than to futz around trying to replace individual definitions, crafing intricate ldif modify directives.
As it turns out, cn=config is NOT stored in the database (though the documentation misleads about this)...it is stored in a special subdirectory (/etc/ldap/slapd.d/cn=config on my Ubuntu boxes). Maybe it's loaded into the db at startup...I don't know. Not sure this is much better than the old slapd.conf approach.
Then Ralf said:
But is very time consuming and resource intensive. E.g. checking for the presence of an AttributeType requires a full scan of the database if that AttributeType is not indexed, I think. Additionally this check would have to be done with the thread pool paused (i.e. no other operation would be processed) or at least with every database set into read only mode, to avoid races. I am not even sure if it would be possilbe with all backends types that we currently support (think of back-ldap or back-meta).
Hmmm...sounds like a classic referential integrity issue. Triggers can be your friend! ;-)
But the safest option we can currently offer, IMO.
Sounds like it...though that makes me shudder, having some dbms background.
And yes of course things can always be improved. Help with that is always welcome, BTW.
'Fraid I have limited time to devote to open source (read: unpaid) projects, and all my spare time is already committed to another open source project (eXist...XML database).
So the best I can do is to ask questions and offer suggestions at this time, wrt OpenLDAP.
Then again, I did recently write and donate an eXist extension module that lets you easily query an LDAP directory using high-level functions in an XQuery. Does that count? ;-)