On 2/4/12 12:21 AM, Alex Karasulu wrote:
On Thu, Feb 2, 2012 at 10:10 PM, Emmanuel Lecharny<[email protected]>wrote:
For the former issues, which has been raised when we started to try to
extend the API to allow a user to add new Schema elements locally, we think
that we must modify the current data structure for schema objects.
Here are a few brain dump and some examples :
First, the SchemaManager will only manage immutable SchemaObjects (ie,
here, AttributeType), as there is no reason to allow someone to pull a
SchemaObject from the SchemaManager and to modify it on the fly. That would
be destructive for the sc hemaManager user, as it may impact other users.
Right you don't want to mess with the in memory structure (graph of schema
objects) that is managed by the schema manager directly.
Only when we expose those schemaObjects to the public. Something that
will become real if we expose the SchemaManager to the public in the API.
On the server, it's a non issue, if we are careful as developpers.
We then discussed about Mutable and Immutable schema objects, and how they
can help us solving this issue.
If a user want to modify an existing SchemaObject pulled from the
SchemaManager must first make it mutable :
AttributeType attributeType = schemaManager.**getAttributeType(
"2.5.4.11" );
MutableAttributeType mat = new MutableAttributeType( attributeType );
In this case, the resulting instance is a copy of the initial immutable
object.
Will the mutable will track the differences (the deltas) in the mutable
from the original schema object being wrapped?
As the SchemaManager holds only immutable objects, mutable objects are
only copies of those immutable objects. We don't track change, namely.
We can diff them, but I'm not sure it's relevant.
Thoughts ?
I would like to share a view I have in my head about all the in memory
schema data structures we have. Just a quick review as some points/facts
first:
(1) We have schema objects that directly reference other schema objects
resulting a graph of schema objects.
Yes. I have a graph I draw years ago about all the relations between all
the objects. I can share it if needed (not now, I'm in a train but I can
add it on a wiki page).
(2) The designed model of schema objects let's the containment hierarchy
naturally walk the graph. Like for example looking at the MAY list of an
ObjectClass will reference actual AttributeType objects in the graph
connected to the ObjectClass. Further walking the AT object to see it's
Syntax and MatchingRules does the same.
(3) Registry objects serve as map structures for rapidly indexing into
pools of schema objects by type based on alias names and their OID.
I would add a very important fact :
4) The only interface to manipulate SchemaObject is the SchemaManager.
Registries are nit anymore exposed to the public, they are internal to
the SchemaManager
NOTE:
Contained objects like a Syntax referenced by an AttributeType should not
be directly referenced. Instead the Syntax's OID should be kept in the
AttributeType and an accessor like getSyntax() should use a lookup via the
Syntax Registry. This is important from both an OSGi standpoint and to
easily implement a change mechanism to this grand data structure atomic,
consistent and isolated.
Hmmm. That would be killing, IMO. Doing a lookup is a costly operation,
and if we can avoid doing it, that would be good. I mean, the
SchemaManager contains only immutable objects (or should contain only
immutable objects), so once those objects are loaded into teh SM, they
is no reason to change anything.
Updating the schema is an operation which is done globally : we create a
new SM, load it with the modified SO, and swap it with the old one if
it's checked and validated. I'm pretty sure that using OSGi does not
create a pb in this context.
----
I like the Mutator wrappers introduced in this mail thread above: and I
think it's key to implement a proper change algorithm. I also like the idea
of them serving to just store deltas and track changes from the original
immutable objects that they directly reference. This probably will make the
schema editor code a lot easier to implement.
Well, mutable objects are *not* tracking changes made in immutable
objects. It's just that they use the Immutable objects as a base storage
for fields. It offers an extended 'vision' on the inner data, allowing
the user to modify them.
But you can't take a immutable object, wrap them into a mutable object,
and modify them. To do this implies a copy of the whole immutable object
under the hood.
I see a set of mutators being collected/tracked as a group, then applied in
an atomic batch to the main data structure after a validation test to
determine if the resultant graph is consistent.
This is already what we do.
Then the entire structure
can be read and write locked, and changes to it from the mutators applied
throughout, then the structure unlocked.
It's even easier. The SM instance is a volatile, and you simply swap the
newly created SM with the old one. All the threads using the old SM will
of course be impacted, but at some point, we can live with that :
modifications on a schema shloud not be considered as a light operation,
done in production...
The full structure locking for
readers and writers is acceptable since we rarely perform schema change
operations and it maintains a consistent view.
Yes. See above.
We should also fire some events to inform those that need to listen to
schema changes that something was altered. Sending those listeners the
deltas or mutator objects might be valuable for them to refresh themselves.
That is a bit more complex to implement, and with the way it is done
currently, I don't see a simple path to implement listeners.
We can discuss this further, but that would require a full rework on the
way the schema is implemented...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
