Re: Schema update using back-config

[Howard Chu <hyc@symas.com>]

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=2.5.4.4,cn={0}core,cn=schema,cn=config
   attribute: 2.5.4.4
   name: sn
   name: surname
   description: RFC2256: last (family) name(s) for which the entity is 
known by
   sup: name

   dn: object=2.5.6.2,cn={0}core,cn=schema,cn=config
   object: 2.5.6.2
   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