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 Fri, 10 Feb 2006 13:51:36 GMT
#: 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 <the.mindstorm.mailinglist@gmail.com> 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
> 


Mime
View raw message