directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: [ApacheDS] [Schema] New schema subsystem specification
Date Fri, 24 Nov 2006 00:07:06 GMT
On 11/23/06, Alex Karasulu <aok123@bellsouth.net> wrote:
>
> Norval Hope wrote:
> 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?


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.

>  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.
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 :)

> 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?

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)

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.

>  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 ? :)



> 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,
>
> NP.
>
> but even so I see
> > populating at start-up rather then maven plugin + import utility


At some point, I think that your objective is compatible with what we intend
to do with the new design.

-- 
Cordialement,
Emmanuel L├ęcharny

Mime
View raw message