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