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.
