I think we will need to revisit another schema revamp when we try to follow the administrative model for the schema aspect.  You're going to need different registries for different areas.   We had a really cool conversation about all this with Howard at Apache Conference.  Wish you were there to hear it.  Various anamolies and hurdles were discussed.

On Tue, Nov 24, 2009 at 12:56 PM, Ersin ER <ersin.er@gmail.com> wrote:


On Tue, Nov 24, 2009 at 19:46, Emmanuel Lecharny <elecharny@apache.org> wrote:
Ersin ER wrote:
Hi,

 
considering the problem we might face if we allow all modifications in the
schema, I would suggest we implement only a partial support for modification
in the server.

First, we will have a dual mode for the SchemaManager :
- strict, used in the server
- relaxed, used in studio and in the API

If the Schema is in strict mode :
- Add operations will be allowed for AT, C, MR, N, OC, S and SC
- Move operations will be allowed for AT, C, MR, N, OC, S and SC

   

Move? Just a rename or moving a schema object from one Schema to another?
 
Move a SchemaObject from one schema to another one. For instance, move 'cn' from core to system.

Both of them are unsafe. For unsafe operations we should be running a
routine for checking relevant entries in the DIT. Or we should just reject.
 
A move is safe. It does not impact the current instance of the moved SchemaObject but the inner schemaName. All the objects referencing this instance keep this same reference.

I was thinking about subschema administrative areas. Your interpretation of schema is more physical. (And of course you're correct wrt to the discussion and what you're working on.)
Each entry is associated with a subschemaSubentry. Each subschemaSubentry is probably associated with a set of schemas (like core, nis, etc). If a schema object is moved from one schema to another and if that new schema is not referenced in a subschemaSubentry than we may need to do additional work to update the subschemaSubentry. (So yes, as I can see now, what I am talking about is not about the core problem.)
 
- Enabling schemas will be allowed
- All other operations will be rejected (any operation done on DCR, DSR, NF
and MRU, all deletes, renaming, modifications, disabling a schema)
- We can't have two SchemaObject with the same OID in a specific registry

If the Schema is in relaxed mode :
- all the operations will be allowed

   

I do not really know what's your intent with 'relaxed'?
 
A relaxed SchemaManager is useful for the client API or for Studio. The API just need a way to check that the entry you are manipulating are correct, before sending them to the server (but this is not the most important task), it's mostly used to do some comparison of values using the Syntax.

In Studio, as it embeds a Schema editor, it's obvious we need to modify the schema deeply, then we can't accept the mimitations we have. However, as it's just about manipulating the schema, not the entries, we are fine with that.

That's fine as long as we do not use it in server :-)
 
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org



Thanks.



--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org