#: Christophe Lombart changed the world a bit at a time by saying (astral date:
2/10/2006 3:14 PM) :#
Excellent ! No comment until now.
This proposal contains nice flexibilities to solve different uses
cases. I like the option to use the discriminator property or the node
types. It should cover 90% of the inheritance issues.
For the moment I am seeing it covering 100% ;-). Till somebody comes with
missing scenarios.
You are right, we found a lot of inspiration from tools like Hibernate
and OJB. the class-descriptors, ... comes from OJB, the same for
auto-retrieve, auto-update proposal :-)
Now, what about the interface support ? Do you want to speak about
that now or later ?
Interface based support is completely covered by this proposal. Whenever I mentioned class you can
substitute that with interface and that would be it.
./alex
--
.w( the_mindstorm )p.
On 2/10/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote:
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.
--
Best regards,
Christophe
