directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@gmail.com>
Subject Re: [Schema Refactoring] Proposal
Date Tue, 24 Nov 2009 18:00:11 GMT
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.
>
>
> --
> Ersin ER
> http://www.ersiner.net
>



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

Mime
View raw message