[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Schema update using back-config

Quanah Gibson-Mount wrote:
 --On Wednesday, April 13, 2005 12:42 PM +0200 Pierangelo Masarati
 <ando@sys-net.it> wrote:
> Schema files are supposed to change very rarely, most of the times
> when new items are added, seldom when something is modified (e.g.
> when a flaw in some standard track, or as a consequence of some
> ietf clarification, details of an existing schema change), while in
> principle no deletion should ever occur.

 There is also the case of local schema's, which Stanford uses
 heavily.  I would agree that 99.9% of the time we only add to it,
 although I've found an instance now to modify one objectClass because
 in hindsight it was defined incorrectly. ;)  Just keep in mind that
 there are other schema's about that may or may not stick to the
 general rule of only having additions.

At some point down the road we can tackle this fully. I guess that editing the definition of an existing element should be possible, but the current organization makes it difficult. A sensible suggestion was to make each schema element entries unto themselves, with their individual fields being represented as attributes. Then you can separate the act of editing a definition from the act of deleting and re-creating it. Since the big problem here is cached Attribute references and superior/subtype inheritance trees, I'd say we will never be able to delete any loaded definitions from a running server. (It's not worth the effort to add reference counters to these things.) But tweaking some fields within a definition can probably be done safely.

The idea would be to preserve the current cn=schema,cn=config contents as-is, so e.g. cn={0}core,cn=schema,cn=config will still
contain the standard-format for the definitions. But additionally, it will have children for each schema element, e.g.
dn: attribute=,cn={0}core,cn=schema,cn=config
name: sn
name: surname
description: RFC2256: last (family) name(s) for which the entity is known by
sup: name

dn: object=,cn={0}core,cn=schema,cn=config
name: country
description: RFC2256: a country
sup: top
type: structural
must: c
may: searchGuide
may: description

Editing a child entry will alter the definition of that schema element (and the change will of course be visible from the parent cn={xx}foo,cn=schema,cn=config object simultaneously). These would be virtual entries, generated from the parent object and never saved in the backing store.

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support