#: 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 <[EMAIL PROTECTED]> 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
