incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <>
Subject Re: How can aggregation be mapped in OCM?
Date Mon, 04 Sep 2006 08:36:47 GMT
Here are some comments on aggragations, references, ... :

1/ The REFERRENCE feature is not yet supported in the OCM frameworks.
I think only a new BeanConcerverter impl is required (or maybe almost
nothing). Any kind of contribution is welcome.

2/ For aggragation defined in the subnodes, it is possible to use the
proxy features to maximize performance. As you certainly know, the
beanConverter and CollectionConverter are there to retrieve, update,
delete some aggregated objects. You can also disable some actions on
aggragations (retrieve, insert/update, delete) with the attribtures

3/ There are a BeanConverter impl which gives the Parent Object (of
course based on the Parent node). See the class
ParentBeanConverterImpl. There is a small unit test.

Kind regards,

On 9/4/06, Dan Connelly <> wrote:
> Alex:
> I see that the JCR spec uses the term "Multiple Parents" for roughly the
> same concept as aggregation.
> Maybe the problem I am having is somehow due to the fact that the "hard
> links" support for Multiple Parents, method
>  addExistingNode(String absPath)
> in the javax.jcr.Node interface, was dropped from the API (although the
> spec continues to describe it).
> The on-line discussion I am finding concerning nodes with "Multiple
> Parents" says that soft links using a REFERENCE property (or collection
> element) in all but one parent node is a reasonable substitute for
> aggregation..    The child's jcr node type must have mix:referenceable
> supertype.
> The soft link solution is okay with me, but I see no support for even
> that in the Graffito jcr mappings.   Am I wrong?

> What did you mean by a "custom bean discriptor"?    I am open to any OCM
> solution but I do not see any features in bean-discriptor that cover
> REFERENCE as a jcrType.   It is possible that I could use a hack by
> mapping a bean property as a field-descriptor and then suppling a custom
> object converter to insert a REFERENCE value in the field's jcr
> property.    That custom object converter class needs to accommodate any
> bean class (for my requirements).   This is non-trivial.
> Also, shared beans are not just bean fields.   They might be elements in
> a collection.    The single field-descriptor hack does not work in that
> case.   There  is no jcrNodeType in the collection-descriptor that would
> force the collection elements to be mapped as  REFERENCE value nodes.
>        -- Dan
> Alexandru Popescu wrote:
> > On 9/3/06, Dan Connelly <> wrote:
> >
> >> How do you express aggregated, not contained, bean references in the
> >> OCM?
> >>
> >> An aggregate bean ref would (presumably) get persisted as a uuid uri,
> >> not as a content sub-node.    (Path references might be okay instead of
> >> uuids.)
> >>
> >> If I map naively with two classes that where each has the other as a
> >> bean element, then pm.insert(rootObj) will traverse this loop
> >> endlessly.   The rootObj class has proper containment of both these
> >> mutually referencing classes.
> >>
> >
> > I think you should use a custom bean descriptor to take care of this
> > kind of mapping.
> >
> > ./alex
> > --
> > .w( the_mindstorm )p.
> >
> >>        -- Dan
> >>
> >

Best regards,


View raw message