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.
- 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.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
