directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <ersin...@gmail.com>
Subject Re: [ApacheDS] [Schema] New schema subsystem specification
Date Fri, 24 Nov 2006 05:59:55 GMT
Hi Norval,

Could you please document your proposal on the cwiki. That will be
more organized and won't be lost as in e-mail threads. You may write
it in a comparative/complimantor manner considering the latest
document Alex wrote. So everybody can better understand your
requirement/proposal and I think we can reach a solution much easier
that way.

Documents are good :-)

Cheers,

On 11/24/06, Norval Hope <nrhope@gmail.com> wrote:
> > 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
> registries.
>
> > 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.
>
> Thanks
>


-- 
Ersin

Mime
View raw message