incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandru Popescu <>
Subject Re: OCM - Inheritance & Interface
Date Fri, 10 Feb 2006 12:19:03 GMT

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
covering scenarios where nt:unstructured or some other very generic node type is used for
  a hierachy of classes.

Inheritance behaves normally: all subclasses are inheritting properties/nodes from their parent

Note: To differentiate between the classes the mapping should define a discriminator property:
property that determines what the real type of the corresponding object in hierarchy. Without
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.


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
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 of the JCR

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
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

For the "node per subsclass" strategy this would suppose searching for nodes having the node
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
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
to think about it and feel free to find missing points :-).


.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.

View raw message