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
"auto-*).
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,
Christophe
On 9/4/06, Dan Connelly <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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,
Christophe
