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 Mon, 13 Feb 2006 14:13:12 GMT
#: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/13/2006 12:23
PM) :#
> I have comments after reviewing for the second time your proposal and
> the proposed new attributes :
> 
> 1. I'm wondering why the polymorhpism attribute is specified in the
> classdescriptor ?
> It is mainly used to build queries to exclude or not the subclasses.
> right ? Why not to specify it in the Query API (the query class). By
> this way we can support both query techniques on the same class
> hierarchy

At a first glance this looks good. Still, I need to think about it, before agreeing 100%.

> I'm just wondering if there is some use cases where it should be
> possible to support implicit and explicit queries.
>

I am sure there are cases when you would like to query for all file (not considering their
type) or 
query for specific types of files).

> 2. When abstract is used ?
> 

You can define classes that are part of the hierarchy, part are not gonna be persisted/retrieved
by 
their own, but only through their subclasses.

> 3. extends-type is maybe not necessary. It can be calculated with the
> discriminator ?  If I understand the discriminator is only used in the
> node type per hierarchy strategy.
>

You are suggesting that we should determine the extends type from the usage of the discriminator?

This may work indeed. I must think about it.

thanks for the suggestions and questions. I will get back to you as soon as i have some good
answers.

./alex
--
.w( the_mindstorm )p.


> 
> On 2/11/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
>> #: Alexandru Popescu changed the world a bit at a time by saying (astral date: 2/10/2006
2:19 PM) :#
>> > 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.
>> >
>>
>> I think these attributes are enough to have me started with the inheritance support:
>>
>> graffito-jcr
>>         - package: would simplify class names
>>
>> class-descriptor
>>         - extends="(nothing)|classname"
>>         - extends-type="concrete|hierarchy"
>>         - polymorphism="implicit|explicit"
>>         - abstract="true|false"
>>         - discriminator-value only for nodetype-per-type-hierarchy
>>
>> field-descriptor
>>         - descriminator="true|false"
>>
>> What do you think?
>>
>> ./alex
>> --
>> .w( the_mindstorm )p.
>>
> 
> 
> --
> Best regards,
> 
> Christophe
> 


Mime
View raw message