incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Connelly <dsconne...@adelphia.net>
Subject Re: How can aggregation be mapped in OCM?
Date Mon, 04 Sep 2006 01:57:08 GMT

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 <dsconnelly@adelphia.net> 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
>>
>


Mime
View raw message