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

[Andrzej Jan Taramina <andrzej@chaeron.com>]

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