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 <[EMAIL PROTECTED]> 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
