Alex Karasulu wrote:
> Thinking more about how to update the schema and the mechanics involved
> along with the various trade offs.  Here's how this should progress:
>
> Schema Change Steps
>
> (1) A schema change operation arrives and changes are performed on a cloned
> set of registries where the impact of the change is calculated in terms of
> the total number of indirect dependents affected.
>   
As of today, the clone is mainly used to check that the registries 
remain consistent after the changes. Calculating all the impacted 
elements is a bit complex...
> (2a) If the operation is consistent then a schema-txn-begin message is sent
> to all listeners informing them of the OIDs impacted by the schema change
> calculated in the first step.  This lets objects dependent on these schema
> entities to respond to the situation. This message is delivered
> synchronously.  Access to the old Registries is provided before the swap in
> case the object needs them via the SchemaManager handle if they are exposed.
> (2b) If the operation leaves the schema in an inconsistent state then no
> message is sent to schema listeners and the schema change is rejected.
> (3) The schema registries are swapped out.
> (4) The SchemaManager then sends a schema-txn-commit message to all
> listeners to now be able to access the modified schema elements they're
> interested in from the newly swapped in registries.  This message is
> delivered synchronously.
>
>
> Schema Change Responses
>
> (1) Invalidate the object in question so all using/run processes and caches
> can reset or update themselves via the acquisition of a new valid object to
> continue the process.
> (2) Make the object depending on schema objects valid by updating stale
> references and hope for the best.  Sometimes timing will cause certain
> failures but this is really OK with us since this is a rare situation to
> update the schema.
>   
If the object has already been checked by the SchemaInterceptor, and if 
the schema modification makes this object to be inconsistent, we won't 
be able to fix that, as the chek has already be applied.
>
> SchemaListener Interface Methods
>
>    schemaChangeBegin( SchemaManager sm, List<String> oids );
>    schemaChangeCommit( SchemaManager sm, List<String> oids );
>
> Pulled these out of my arse so please elaborate.
>   
My guts say that it's far too complex to implement right now. My kidneys 
feel that it might even don't work correctly : too many corner cases...

IMHO, we shoudl try to get the server back on rail, even without all 
those dynamic schema modifications, except for the additions operation 
and for the schema enabling operation.

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org