directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [ApacheDS] [Schema] New schema subsystem specification
Date Thu, 23 Nov 2006 19:24:48 GMT
Norval Hope wrote:
>  1. I'd be much happier if the ".schema file => schema partition"
> tool were instead (or also) available as an optional start-up
> mechanism activatable by uncommenting support in server.xml. In the
> use-cases dear to my heart users are able to easily register dynamic
> custom partitions along with the .schema files they depend on by
> simply placing files in various filesystem directories (ala
> appservers) rather then having to run separate utilities. 

The utility can also generate an LDIF from .schema files (to add schema 
changes) that can be applied once on startup which effectively gives you 
what you want right?

Given this
> point I'd most probably do away with a maven plugin for the ".schema
> => schema partition" bit and replace it with code to determine whether
> the .schema partition needed to be populated with bootstrap
> information on its first run after deployment (from .schema files
> included in a release .jar). For dynamic updates/additions of .schema
> files the relevant filesystem directories could be polled for changes
> periodically (again ala appservers).

Yeah there is a problem here with having 2 copies of the same data. 
Which one is the authoritative copy?  We'll have the same data in a 
.schema file on disk and in the DIT.  Where do we make changes when the 
schema is altered via the DIT?  What do we do if the schema files are 
changed on disk?  What if there are conflicts?  How will they be resolved?

>  2. Being able to change schema information is a very power-user
> feature, but I'd imagine that a much more common usage is simply
> wanting to add extra read-only schema information (matching various
> RFCs and/or basically static schemas defined by third party vendors)
> after deployment. In my usecases storing the thirdparty (i.e.
> non-core) schema information persistently is actually a minus rather
> then a plus; I'd prefer my users could deploy another custom partition

Another partition?

> with updated schema information and restart AD without having to worry
> about clashes with existing information. Is it theoretically possible
> to indentify various schema subtrees as "read-only" so that they can't
> be changed and aren't persisted, but are instead transiently populated
> from .schema files at start-up?

Might be able to do this but I'm very against the idea of parsing 
.schema files on startup.  Plus there are things you cannot store in 
.schema files that you can store in the DIT.  Like normalizers, 
syntaxCheckers and comparators.

>  3. Whether modifying schema information via piece-meal updates or
> whole .schema file imports, we face questions re versioning / draining
> of pending requests referring to old version of the schema etc. Is the
> race condition between schema changes and other operations referring
> to the schema some that needs to be considered now, say by
> synchronizing access to the schema partition.

Schema information under this new design is just like any kind of data 
within the server.  The same shared/exclusive lock requirements apply 
wrt read/write opertions.

> I know my focus is out of whack with AD's primary objectives, in that
> I don't use it as a persistent store at all, 


but even so I see
> populating at start-up rather then maven plugin + import utility 

Note that this maven plugin is not for general use.  It is used to 
pre-build the schema partition that will be deposited on disk if the 
schema partition has not yet been created.

As for the import utility it can just generate an LDIF of that you can 
load on startup.  You can provide schemas in LDIF format for your users. 
  The good thing with AD is that if you load an LDIF on startup AD marks 
that LDIF file as already having been loaded and will not load it again.

It keeps a record of what was loaded when under the ou=system area.

as a
> universal plus in terms of flexibility / amount of code required.

I think some points I did not make clear.  The schema partition is a 
single partition that will always be present just like the system 
partition.  You will not be loading schema info into just any partition. 
  This partition is dedicated and fixed at ou=system.  Regardless of the 
VD you're building you'll still need to have this schema partition or 
ApacheDS or your derived virtual directory will not start.

What are some of your requirements for the VD you're working on?


View raw message