directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norval Hope" <>
Subject Re: [ApacheDS] [Schema] New schema subsystem specification
Date Fri, 24 Nov 2006 05:09:17 GMT
> I agree with alex : the fact is we must have an invariant somwhere. If the
> schema can be changed on the fly, that means we also have to modify the data
> on the fly, which is almost impossible to  imagine. I will tend in favor of
> having the meta-schema being the authoritative, except if an admin decide it
> should be change in some way.

See my previous post, for my cases of interest the schema data would
be best treated as "read-only" pass-through info for AD. Hence it
would only be in-memory (or transiently stored in the schema partition
until the next server restart, or until it was no longer needed if
that came earlier).

> > >  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?
> You may want to allow the user to use ADS as a Ldap Server the same way a
> user use a n application server : he uploads its schema, create uts
> partition on the fly, then use it, but will be confined to its partition.

This is precisely what I do in my use-cases. However, there isn't
currently any notion of a schema being attached to a partition (and
hence unloadable with it) so it needs to be made known in the global

> That seems an interesting idea, but at some point, it goes farther than just
> having dynamic schemas. You have to remember that OIDs are supposed to be
> unique. If you have two admin of two distincts partitions on the same ADS,
> then you may have 2 objects with the same OID. Not that it's impossible to
> manage, but this is a little bit more complicated. You can see it as if you
> have more than one instance of ADS running, excepts that you have only one
> port. That also mean you duplicate the registries. There are some ideas to
> dig :)

Indeed there are versioning issues which I address by mandating a
single version of each schema is shared by all custom partitions that
reference it, which equates in my current scheme to only a single
.schema file. As the schemas are read-only once loaded there isn't too
bad a problem, and at any rate its solution lies outside of AD's
domain (instead its a restriction I inform people writing custom
partition bundles about).

> > > 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.
> Well, I will say that I'm not really against a 'parse at startup' system,
> but at some point, I don't think it's the best solution. Parsing schemas is
> not expensive, but the main problem is that you are having a problem which
> has already been expressed in point 2 above : who is the authoritative
> element?

Sure, but this isn't an issue if the schema info is read-only to AD in
which case both the file and the in-memory (or transiently in
schema-partition) representations match. I'm not suggesting this will
be the case for all schema info, just the schema info for which AD is
merely acting as a pass-through (i.e. not responsible for persisting
any objects that are described by the schema).

> Now, what we can have is a client tool which could manage the schema
> (instead of writing files). LdapStudio is intended to do that soon. I can't
> see a lot of scenario where you will be able to modify the schema in a
> production server, so dropping a schema files somwhere expecting the server
> will read it. A Ldap server is not really very close to an AppServer, in my
> mind. (but some scenario might exist)

In my usecases this can happen every time a new version of a custom
partition bundle is deployed, even though the version of the AD system
itself hasn't.

But again the schema is overwelmingly more static then most LDAP
information, and will only be changed extremely rarely (except perhaps
for custom additions) which in my case mean that a new bundle will
have to be prepared (i.e. the bundle's code needs to be updated to
match the new schema and both are then redeployed).

> Further more, as explained by Alex, the matchingRules, syntaxCheckers, etc,
> may be stored as compiled classes and injected into the server, which is not
> possible with static files.

Yeah, I'm not very clear on this side of things. If someone wants to
add an extra (not included in its release) schema to AD  with my
current solution, they just need to plonk a .schema in a special
directory and optionally (very rarely I suspect - see stats for
schemas other then System.schema in my previous reply to Alex) plonk a
.jar containing extra matchingRules etc in lib/ and restart AD. Does
the proposed solution to this problem to require them to rebuild the
server in order to achieve this ?

> > >  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.
> (he he : do we have them ? Or do we _intend_ to have them implemented with
> the new design ? :)

As outlined in my previous post, I think changes to meta information
make the locking problem significantly harder.


View raw message