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? ;-)
--
Andrzej Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
