incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Lombart <christophe.lomb...@gmail.com>
Subject Re: OCM - Inheritance & Interface
Date Mon, 13 Feb 2006 10:23:03 GMT
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.
I'm just wondering if there is some use cases where it should be
possible to support implicit and explicit queries.

2. When abstract is used ?

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.


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