incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandru Popescu <the.mindstorm.mailingl...@gmail.com>
Subject Re: OCM - Inheritance & Interface
Date Wed, 15 Feb 2006 23:07:58 GMT
Hi!

I have finally got confused :-), and I would like to hear your opinion on the following points.

A] Updates

1/ NO INHERITANCE DEFINED

Would it be allowed for an object mapped to node type X to update a node whose node type or
super 
node types is X? or should it be a strict mapping? (an object mapped to node type X should
be 
allowed to update a node only if the node type is X).

My opinion: first approach (allow updating a node whose node type or super node types is X)

2/ NODETYPE_PER_CONCRETECLASS

Same question as above.

My opinion: same as above

3/ NODETYPE_PER_HIERARCHY

Same question as above.

My opinion: same as above.

_Conclusion_: in terms of updates the behavior would be the same disregarding if inheritance.

B] Fetching (getObject)

1/ NO INHERITANCE DEFINED

Would it be allowed to fetch an object mapped to node type X from a node whose node type or
one of 
its super node types is X? or should it be a strict relation? (an object mapped to node type
X 
should be accesible only from a node with node type X)

My opinion: first approach

2/ NODETYPE_PER_CONCRETECLASS

Same question as above.

My opinion: same as above.

3/ NODETYPE_PER_HIERARCHY

Same question as above.

My opinion: same as above.

_Conclusion_: in terms of retrieval the behavior would be the same disregarding if inheritance.

At a first glance, having the same behavior when inheritance is involved or not may look quite

weird. Still, thinking in terms of Liskov principle about node type hierarchy, I would say
that 
things look more clear.

Please let me know what do you think about this.

tia,

./alex
--
.w( the_mindstorm )p.

#: Alexandru Popescu changed the world a bit at a time by saying (astral date: 2/10/2006 2:19
PM) :#
> Hi!
> 
> Here is my proposal for handling inheritance:
> 
> 1/ Node type per class hierarchy
> 
> Scenario: all hierarchy classes are using the same node type for persistence. This strategy
is 
> covering scenarios where nt:unstructured or some other very generic node type is used
for persisting 
>   a hierachy of classes.
> 
> Inheritance behaves normally: all subclasses are inheritting properties/nodes from their
parent classes.
> 
> Note: To differentiate between the classes the mapping should define a discriminator
property: a 
> property that determines what the real type of the corresponding object in hierarchy.
Without this 
> requirement, queries cannot be performed.
> 
> Constraint: if the node type has mandatory properties/nodes, than these must be mapped.
Otherwise, 
> the storage will not work.
> 
> Example:
> 
> As a quick example thing about the scenario where People is extendend by Student and
Teacher 
> classes, and both Student and Teacher are persisted using a node type: nt:people.
> 
> 2/ Node type per subclass
> 
> Scenario: each non-abstract subclass is using its own node type for persistence. This
strategy is 
> covering scenarios where very specific node types are used for mapping real classes.
> 
> Details: there are no visible problems/constraints regarding this scenario. Inheritance
behavses 
> normally: all subclasses are inheritting properties/nodes from their parent classes.
> 
> Constraint: the parent node under which the subtree of these classes is hosted must be
generic 
> enough to support different node types (f.e. nt:unstructured).
> 
> 3/ Implicit/Explicit polymorphic queries
> 
> As Marcel Reutegger (Jackrabbit committer) pointed: according to section 6.6.3.2 of the
JCR spec:
> 
> A type constraint specifies the common primary node type of the returned
> nodes, plus, possibly, additional mixin types that they also must have.
> Type constraints are inheritance-sensitive in that specifying a
> constraint of node type X will include all nodes explicitly declared to
> be type X, as well as all nodes of subtypes of X.
> 
> Translating this in Java hierarchies:
> 
> when searching for an object type X, than the query will return by default all nodes
of type X or 
> any subtype of X.
> 
> 
> For the "node per class hierarchy" strategy this will use the discriminator property
value to 
> instantiate the correct subtypes of X. Without the discriminator property, there is no
possible 
> solution to identify the correct subtype of X to be instantiated.
> 
> For the "node per subclass" strategy this will use the union of all node types corresponding
to the 
> X and all its subclasses.
> 
> Note: the same strategy can be applied to search using interfaces.
> 
> Explicit polymorhic query:
> 
> However, there are cases when explicit polymorphic queries should be used. In this case,
querying 
> for a type X will return only nodes corresponding to X class, disregarding any nodes
that map to a 
> subclass of X.
> 
> For the "node per class hierarchy" strategy this would suppose searching for nodes type

> corresponding to the specified hierarchy and for discriminator="condition to match only
type Y"
> 
> For the "node per subsclass" strategy this would suppose searching for nodes having the
node type 
> exactly matching the class, dismissing any nodes that correspond to possible subtypes.
> 
> Supporting all these behavior in mapping would imply:
> - creating special mappings support for the 2 strategies (node type per class hierarchy
and node 
> type per subclass)
> - adding an attribute specifying what is the polymorphic behavior: implicit or explicit.
> 
> In my opinion this proposal covers a wide range of scenarios, hopefully all. Please take
your time 
> to think about it and feel free to find missing points :-).
> 
> cheers,
> 
> ./alex
> --
> .w( the_mindstorm )p.
> 
> ps: I must give credit for the inspiration and some good ideas to Hibernate guys and
all other 
> contributers to ORM tools.
> 


Mime
View raw message